USB-перенаправлення в Proxmox: відключення, автоматичне призупинення живлення та виправлення стабільності

Швидкий план діагностики

Коли USB-перенаправлення ламається в проді, немає часу на танці з бубнами. Потрібна чітка послідовність, яка розділяє: відмову пристрою, проблеми з живленням, управління живленням ядра, поведінку скидань контролера та віртуалізаційну обв’язку.

Перш за все: визначте, де відбувається відключення

• Тільки на хості? У журналах ядра хоста видно відключення та повторну ініціалізацію. Гість/контейнер просто бачить «пристрій зник». Спочатку виправляйте живлення/PM/контролер на хості.
• Тільки в гості? Хост бачить стабільний USB, але драйвер гостя робить скидання. Зосередьтеся на ядрі гостя, виборі USB-емуляції QEMU та способі передачі пристрою.
• Фізична проблема? Індикатор пристрою блимає/скидається, хаб клацає, або інші пристрої на тому ж хабі також відключаються. Виправляйте живлення, кабель, хаб або порт.

По-друге: зафіксуйте докази під час події

• Запустіть dmesg -Tw на хості Proxmox під час відключення.
• Перевірте журнали гостя з тим самим часовим штампом.
• Порівняйте, чи відбуваються скидання шини (usb X-Y: reset) або відключення пристрою (disconnect).

По-третє: класифікуйте режим відмови

• Brownout / недостатня напруга: відключення під навантаженням; хаб або порт показує події живлення; кілька пристроїв можуть відпасти одночасно.
• Автоматичне призупинення (autosuspend): відключення після періоду простою; повторюваний інтервал; пробудження по трафіку та флапи.
• xHCI скидання та особливі випадки: «xHCI host controller not responding» або часті «reset SuperSpeed Gen 1 USB device» у логах.
• Неправильний підхід до перенаправлення: передача USB-пристрою в QEMU працює до повторної ініціалізації з іншим шляхом; потрібно передавати по шині/порту або весь контролер.

По-четверте: застосуйте найменше ефективне виправлення

• Поміняйте кабель/порт/хаб і за потреби використайте живлений хаб.
• Вимкніть autosuspend для конкретного пристрою (не глобально, якщо тільки не відчайдухи).
• Якщо хронічні скидання xHCI: передайте весь USB-контролер через PCIe (IOMMU) або застосуйте консервативні quirks ядра.

Як фактично відмовляє USB-перенаправлення (і чому це не випадково)

USB на людському рівні оманливо простий: підключив — працює. Під капотом це переговори між пристроєм, хабом, контролером хоста, драйверами ядра й політиками живлення. Додайте віртуалізацію — і тепер у цих переговорах задіяні два ядра й гіпервізор.

Більшість «випадкових» відключень USB підпадають під кілька передбачуваних моделей:

• Нестабільна ініціалізація: пристрій відключається й повертається з новою адресою. Якщо ваше перенаправлення прив’язане до крихкого ідентифікатора, гість його втрачає.
• Runtime power management: Linux намагається заощадити енергію, призупиняючи пристрій. Деякі пристрої сприймають це як «пора панікувати».
• Цілісність сигналу: сумнівні кабелі, неекрановані подовжувачі та перевантажені хаби створюють CRC-помилки та скидання, особливо на USB 3.x швидкостях.
• Поведінка скидання контролера: xHCI-контролери можуть потрапляти в цикли скидань за певних умов, а логіка відновлення ядра не завжди щадна для довготривалих сесій.
• Віртуалізовані затримки та буферизація: драйвери гостя іноді поводяться по-іншому, коли USB-транспорт емулюється або опосередковується через QEMU замість нативного доступу.

Є ще одна сувора правда: багато популярних USB-донглів (Zigbee, Z-Wave, RTL-SDR) були розроблені для хобі-ПК, а не для цілодобових серверів, що стоять за галасливим хабом на полиці. Їх все ще можна зробити надійними. Просто потрібно ставитися до них як до виробничої залежності, а не як до милих аксесуарів.

Парафраз ідеї Вернера Фогельса (CTO Amazon): надійність будується, якщо припускати, що речі виходитимуть з ладу, і проектувати так, щоб відмови не ставали аваріями.

Жарт перед читанням логів: USB означає «Unexpected Sudden Bye-bye». Це не офіційно, але підходить до тікетів.

Цікаві факти та історичний контекст (корисно, не тривіально)

1. Автоматичне призупинення USB в Linux існує вже роки, і воно стало агресивнішим через налаштування для ноутбуків. Сервери успадковують ці налаштування, якщо ви їх не перекриєте.
2. xHCI замінив EHCI/OHCI/UHCI з приходом USB 3.x, консолідувавши складність в одній моделі контролера. Гарно для можливостей; іноді — виклик для стабільності.
3. USB-адреси пристроїв не є стабільними ідентифікаторами. Вони присвоюються під час ініціалізації й можуть змінитися після скидання. Якщо ваша конфігурація орієнтується на змінну адресу, вона рано чи пізно зламається.
4. Деякі порти USB 3 на материнських платах діляться внутрішніми хабами, тобто два фізичні порти можуть бути одним логічним root hub. Скидання може вивести з ладу обидва.
5. Історично USB-перенаправлення віртуальних машин починалося з емуляції контролерів (UHCI/OHCI/EHCI у QEMU). Сучасні конфігурації віддають перевагу passthrough пристрою або всього контролера для надійності.
6. Selective suspend у Windows і autosuspend у Linux вирішують схожі проблеми, але з різними важелями. Багато пристроїв тестувалися під Windows за замовчуванням, а не під серверними налаштуваннями Linux.
7. USB 3.x використовує додаткові пари «SuperSpeed» поверх дротів USB 2.0. Кабель, що «працює» на USB 2.0, може феєрично провалитися на USB 3.x швидкостях.
8. PCIe passthrough USB-контролера часто вирішує нестабільність, прибираючи шар емуляції і даючи гостю нативний контроль — але втрачається гнучкість.

Практичні завдання: команди, виводи та рішення

Це реальні операційні завдання, які можна виконати на хості Proxmox. Кожне завдання містить: команду, на що дивитися і яке рішення ухвалити далі. Виконуйте їх під час нормальної роботи і під час відмови, якщо можете.

Завдання 1: Слідкуйте за подіями ядра хоста в реальному часі

cr0x@server:~$ sudo dmesg -Tw
[Thu Dec 26 11:18:02 2025] usb 2-2: USB disconnect, device number 7
[Thu Dec 26 11:18:03 2025] usb 2-2: new full-speed USB device number 8 using xhci_hcd
[Thu Dec 26 11:18:03 2025] usb 2-2: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[Thu Dec 26 11:18:03 2025] usb 2-2: Product: CP2102N USB to UART Bridge Controller

Що це означає: Хост втратив пристрій і заново його ініціалізував. Це не «тільки гість».

Рішення: Зосередьтеся на управлінні живленням і кабелях на хості, хабі та скиданнях контролера. Налаштування гостя поодинці не вирішить фізичні відключення.

Завдання 2: Підтвердьте, що Proxmox бачить підключене (VID:PID і шлях)

cr0x@server:~$ lsusb
Bus 002 Device 008: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 002 Device 002: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d6b:0002 Linux Foundation 2.0 root hub

Що це означає: У вас є CP210x на Bus 002. Номер пристрою може змінюватися. Vendor/product стабільні.

Рішення: Уникайте передачі за номером пристрою; використовуйте передавання за vendor/product і фізичним шляхом (host bus/port).

Завдання 3: Отримайте стабільну фізичну топологію (знайдіть ланцюжок порту)

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
    |__ Port 2: Dev 8, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M

Що це означає: Пристрій на Bus 02, Port 2 root hub. Ця фізична прив’язка — якір, який вам потрібен.

Рішення: Якщо пристрій лишається в тому ж порту/ланцюжку, можна створити детерміновані правила udev і конфіги Proxmox для стабільного перенаправлення.

Завдання 4: Перевірте стан керування живленням USB-інтерфейсу пристрою

cr0x@server:~$ DEVPATH=$(udevadm info -q path -n /dev/ttyUSB0); echo "$DEVPATH"
/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0
cr0x@server:~$ cat /sys$DEVPATH/power/control
auto

Що це означає: Увімкнено runtime PM (auto). Ядро може автоматично призупиняти цей інтерфейс.

Рішення: Якщо відключення відбуваються після простою, встановіть on через udev-правило (для конкретного пристрою) або вимкніть autosuspend.

Завдання 5: Перевірте затримку autosuspend для інтерфейсу

cr0x@server:~$ cat /sys$DEVPATH/power/autosuspend_delay_ms
2000

Що це означає: Система готова призупинити після 2 секунд простою. Багатьом донглам це не подобається.

Рішення: Для серійних донглів, координаторів, UPS USB HID та SDR: вимикайте autosuspend для цього пристрою.

Завдання 6: Перевірте USB-контролер і драйвер (xHCI тощо)

cr0x@server:~$ lspci -nnk | grep -A3 -i -i usb
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a36d] (rev 10)
	Subsystem: Intel Corporation Device [8086:7270]
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

Що це означає: Ваш USB-контролер — Intel xHCI на 00:14.0.

Рішення: Якщо згодом ви виберете PCI passthrough контролера, це той пристрій, який слід ізолювати й передати (за умови нормальної IOMMU group).

Завдання 7: Перевірте ввімкнення IOMMU (потрібно для passthrough контролера PCIe)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU" | head
[    0.812345] DMAR: IOMMU enabled
[    0.812678] DMAR: Host address width 39
[    0.813210] DMAR: DRHD base: 0x000000fed91000 flags: 0x0

Що це означає: VT-d/IOMMU увімкнено й ядро його бачить.

Рішення: Можна розглядати передачу всього USB-контролера, якщо він у прийнятній IOMMU групі.

Завдання 8: Визначте IOMMU групу для USB-контролера

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do
  if [[ "$d" == *"0000:00:14.0"* ]]; then echo "USB controller is in: ${d%/*}"; fi
done
USB controller is in: /sys/kernel/iommu_groups/5/devices

Що це означає: Контролер у групі 5. Тепер потрібно підтвердити, що в групі 5 немає пристроїв, якими ви не можете пожертвувати VM (наприклад, SATA або NIC).

Рішення: Якщо в групі є критичні пристрої, не передавайте цей контролер; використайте окрему PCIe USB-картку.

Завдання 9: Перелічіть усе в тій же IOMMU групі

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups/5/devices
0000:00:14.0
0000:00:14.2

Що це означає: У групі є ще один пристрій (00:14.2). Потрібно його ідентифікувати перед passthrough.

Рішення: Якщо це, наприклад, Intel PCH thermal або MEI, можна прийняти рішення; якщо це зберігання/NIC — зупиніться.

Завдання 10: Перевірте конфіг Proxmox VM на предмет крихкого USB-мапінгу

cr0x@server:~$ sudo cat /etc/pve/qemu-server/101.conf
agent: 1
boot: order=scsi0;net0
cores: 4
memory: 4096
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
scsi0: local-lvm:vm-101-disk-0,iothread=1,size=32G
usb0: host=10c4:ea60

Що це означає: Ця ВМ передає пристрій за VID:PID, що зазвичай добре. Але якщо у вас кілька ідентичних донглів, може бути вибрано неправильний.

Рішення: Якщо є більше одного однакового пристрою, передавайте за шляхом шини/порту або використайте udev для створення стабільних симлінків і прив’язки за серійним номером/шляхом.

Завдання 11: Підтвердьте, чи пристрій має серійний номер для прив’язки

cr0x@server:~$ sudo udevadm info -a -n /dev/ttyUSB0 | grep -E "serial|idVendor|idProduct" | head -n 10
    ATTRS{idVendor}=="10c4"
    ATTRS{idProduct}=="ea60"
    ATTRS{serial}=="01A2B3C4"

Що це означає: Чудово: експонований стабільний серійник. Це золото для правил і стабільного призначення.

Рішення: Напишіть udev-правила, щоб встановити power/control і створювати стабільні симлінки, прив’язані до серійного номера.

Завдання 12: Перевірте, чи usbcore autosuspend увімкнено глобально через cmdline ядра

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on

Що це означає: Немає явного налаштування usbcore.autosuspend. Працюють значення за замовчуванням (часто autosuspend увімкнено).

Рішення: Краще робити виправлення для конкретного пристрою, але для діагностики можна тимчасово поставити usbcore.autosuspend=-1, щоб перевірити гіпотезу.

Завдання 13: Переконайтеся, чи runtime PM фактично призупиняє пристрій

cr0x@server:~$ cat /sys$DEVPATH/power/runtime_status
suspended

Що це означає: Інтерфейс зараз призупинено. Якщо сервіс очікує постійної присутності, це тривожний знак.

Рішення: Вимкніть autosuspend для пристрою і спостерігайте, чи припинилися відключення.

Завдання 14: Перевірте патерни xHCI «контролер не відповідає»

cr0x@server:~$ journalctl -k -b | grep -i -E "xhci|host controller|not responding|reset" | tail -n 12
Dec 26 10:55:14 server kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
Dec 26 10:55:14 server kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Dec 26 10:55:15 server kernel: usb 2-2: USB disconnect, device number 7
Dec 26 10:55:17 server kernel: xhci_hcd 0000:00:14.0: xHCI Host Controller
Dec 26 10:55:17 server kernel: xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2

Що це означає: Це скидання на рівні контролера. Все під цим контролером відпаде, а не лише ваш донгл.

Рішення: Перестаньте втрачати час на покращення конкретного пристрою. Використайте інший USB-контролер (додайте PCIe-карту) або передайте виділений контролер у ВМ.

Живлення та цілісність сигналу: непримітна коренева причина

Якщо ви хочете стабільного USB-перенаправлення, почніть із припущення, що ваша конфігурація недостатньо живить або електрично «брудна». Це припущення часто вірне, і воно дешевше, ніж гонитва за примарними багами.

Поширені патерни пов’язані з живленням

• «Відключається під навантаженням»: зовнішній SSD відпадає під час бекапу; SDR-донгл відключається при інтенсивному знятті; Zigbee-стик відпадає під час передачі.
• «Кілька пристроїв відпадають разом»: вказує на скидання хабу/контролера або просідання шини живлення.
• «Працює на десктопі, падає на сервері»: десктоп-порти часто мають іншу топологію хабів і кращі кабелі фронт-панелі, ніж випадковий внутрішній адаптер у сервері.

Що робити (офіційна думка)

Використовуйте живлений хаб для низькоякісних донглів і довгих кабельних ділянок. Так, навіть якщо пристрій «повинен» споживати мало енергії. Багато донглів нормально працюють у середньому, але роблять піки споживання у невдалі моменти. Регулятор і ємність конденсаторів у хабі часто вирішують проблему.

Уникайте дешевих USB 3 кабелів. Цілісність сигналу USB 3 менш поблажлива. Якщо потрібен довгий кабель, використайте якісний або тримайте швидкість на USB 2, якщо можливо.

Віддавайте перевагу заднім портам на материнській платі. Фронт-панельні хедери та внутрішні перехідники — це податок на надійність.

Як довести, що це живлення

• Відключення корелюються з активністю пристрою, а не з часом проста.
• Переміщення на живлений хаб або інший порт зменшує або усуває відключення.
• Ви бачите повідомлення про «over-current» або «power surge» (рідше, але дуже показово).

Другий жарт: живлений хаб — це лист вибачення фізиці з блоком живлення прикріпленим.

Автоматичне призупинення (autosuspend) і runtime PM: тихий вбивця пристроїв

Runtime power management у Linux — хороша ідея з поганою звичкою: воно припускає, що пристрої реалізують специфікацію коректно. Багато реалізують. Деякі — взагалі ні. Для USB-послідовних адаптерів, радіокоординаторів і пристроїв, що імітують HID, autosuspend може спричиняти флапи або «пристрій зник», що виглядає як апаратна відмова.

Три підходи від найкращого до гіршого

1) Вимкнути autosuspend для конкретного пристрою через udev (рекомендовано)

Знайдіть ідентифікуючі атрибути (vendor/product, serial або інтерфейс) і змусьте power/control=on для цього пристрою. Це зберігає runtime PM для всіх інших.

cr0x@server:~$ sudo tee /etc/udev/rules.d/99-usb-no-autosuspend.rules > /dev/null <<'EOF'
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="10c4", ATTR{idProduct}=="ea60", TEST=="power/control", ATTR{power/control}="on"
EOF
cr0x@server:~$ sudo udevadm control --reload-rules
cr0x@server:~$ sudo udevadm trigger

Що це означає: Нові підключення, що відповідають VID:PID, матимуть runtime PM примусово вимкнено.

Рішення: Якщо ваш пристрій відключається після простою, це зазвичай перше надійне виправлення.

2) Вимкнути autosuspend глобально (використовуйте для тестування, уникайте як постійне рішення)

Налаштування usbcore.autosuspend=-1 вимикає autosuspend для всіх пристроїв. Це корисно для швидкої перевірки причинності у інциденті. Але це дробовик.

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="usbcore.autosuspend=-1 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-4-pve
done

Що це означає: Наступний завантаження вимкне USB autosuspend глобально.

Рішення: Якщо стабільність покращиться, повертайтеся і реалізуйте per-device udev-правила замість того, щоб залишати це надовго.

3) Тримати пристрій «пробудженим» трафіком (іноді необхідно, часто огидно)

Дехто запускає періодичні читання/записи або опитування, щоб не дати пристрою заснути. Це обхід, коли прошивка пристрою крихка. Але це також шлях до того, що cron job стане «критичною інфраструктурою».

Рішення: Використовуйте keep-alive лише після того, як доведено, що autosuspend — тригер, і якщо udev power control не може його приборкати.

xHCI скидання, особливі випадки та виправлення на рівні контролера

Якщо в логах видно, що xHCI-контролер помирає й повертається, ви вже не маєте справу з «ненадійним донглом». Це проблема контролера хоста або його взаємодії з прошивкою, PCIe енергоменеджментом чи поганим поєднанням пристроїв на шині.

Впізнайте скидання контролера

Ці патерни мають значення:

• xHCI host controller not responding, assume dead
• HC died; cleaning up
• Переназначення номерів шин після скидання
• Відключення кількох USB-пристроїв одночасно

Ієрархія виправлень (робіть у цьому порядку)

1) Перевірка мікропрограми/BIOS

• Оновіть BIOS/UEFI материнської плати. Баги стабільності USB у прошивках трапляються частіше, ніж хотілося б.
• Вимкніть «ErP» або глибокі режими сну, які можуть впливати на USB-ланцюги живлення, якщо це застосовно.
• Розгляньте відключення PCIe ASPM для серверів, де це не потрібно. ASPM може взаємодіяти з контролерами погано.

2) Додайте виділений PCIe USB-контролер (моє улюблене)

PCIe USB-карта за $20–$50 з адекватним чіпсетом ізолює «проблемні» пристрої від інтегрованого PCH-контролера. Тоді ви можете передати цей контролер або тримати його на хості з налаштованим живленням.

Рішення: Якщо скидання контролера вбивають аптайм, купіть ізоляцію. Це дешевше за ваш час.

3) Передайте весь контролер (PCI passthrough)

Для пристроїв, які ненавидять опосередковане перенаправлення, надання ВМ нативного контролера часто вирішує проблему. Гість бачить нативне обладнання; скидання і повторні ініціалізації лишаються всередині гостя.

Торгові компроміси: втрачаєте доступ хоста до портів, треба правильно управляти IOMMU-групами. Також — live migration може стати складнішим або неможливим залежно від конфігурації.

4) Параметри ядра та quirks (хірургічно, але знайте, що робите)

Іноді можна обійти нестабільність параметрами ядра, що впливають на xHCI або поведінку USB core. Це місце для обережності, бо ви змінюєте поведінку хоста.

Рішення: Якщо виділений контролер вирішує проблему, не ускладнюйте життя експериментами з quirks. Якщо потрібно, документуйте раціонал і спостережувані шаблони в логах.

Вибір режиму перенаправлення (пристрій vs. порт vs. контролер)

Більшість болю при USB-перенаправленні в Proxmox — самозвані проблеми від вибору неправильної гранулярності. Правильний вибір залежить від того, як пристрій поводиться при відключенні й повторній ініціалізації.

Варіант A: Передача USB-пристрою (VID:PID)

Підходить для: унікальних пристроїв зі стабільною ідентичністю, коли повторна ініціалізація не плутає відображення.

Не підходить для: кількох однакових пристроїв або пристроїв, що змінюють ідентифікатори в різних режимах (bootloader vs runtime).

Режим відмови: після перезавантаження може приєднатися не той пристрій або пристрій зникне й повернеться з іншим ID і вже не приєднається.

Варіант B: Передача за шляхом шини/порту

Це більш детерміновано, якщо пристрій фізично лишається в тому ж порту. Менш гнучко, якщо ви переміщуєте кабелі.

Підходить для: лабораторій і серверів, де донгл «частина машини», а не рухомий аксесуар.

Варіант C: Передача всього контролера (PCI)

Підходить для: пристроїв, що потребують низькорівневого доступу, пристроїв з хаотичною повторною ініціалізацією, і конфігурацій, де гість має керувати USB-стеком повністю (часто для Home Assistant VM).

Не підходить для: хостів, яким потрібні ці порти для інших функцій, або коли IOMMU групи не дозволяють безпечної ізоляції.

VM проти LXC: що змінюється, а що ні

Proxmox дає два основні споживачі USB: QEMU ВМ і LXC контейнери. Апаратні реалії не змінюються: живлення — це живлення, контролер хоста — контролер хоста, і ядро хоста все ще в ланцюжку, якщо ви не передали PCI-контролер.

QEMU ВМ

• Ви можете підключати USB-пристрої до ВМ через host passthrough.
• Якщо хост втрачає пристрій, ВМ також його втратить.
• Передача всього контролера через PCIe дає гостю нативну ініціалізацію і часто найкращу стабільність.

LXC контейнери

• LXC ділить ядро хоста. Ви не віртуалізуєте USB-стек; ви надаєте доступ до нодів пристроїв.
• Autosuspend і runtime PM — це поведінка хоста. Виправляйте їх на хості.
• Права доступу і cgroup-правила пристроїв важливі: «відключення» може бути фактично «зміна нода пристрою й контейнер не може його відкрити».

Правило рішення: Якщо вам потрібен стабільний примхливий USB-пристрій, ВМ з передачею PCIe USB-контролера часто найчистіша архітектура. LXC чудовий, але не є межею ізоляції USB.

Поширені помилки: симптом → коренева причина → виправлення

1) Пристрій відпадає рівно через кілька секунд/хвилин простою

Симптом: Працює під час активного використання; відпадає коли тихо; перепідключається при відновленні трафіку; іноді апка гостя не відновлюється.

Коренева причина: USB autosuspend/runtime PM призупиняє пристрій, який не вміє коректно відновлюватися.

Виправлення: udev правило: встановіть power/control=on для VID:PID або серійного номера; опційно перевірте з usbcore.autosuspend=-1.

2) Кілька USB-пристроїв зникають одночасно

Симптом: Zigbee-стик, кабель UPS і клавіатура відпадають одночасно. Номери шин скидаються.

Коренева причина: xHCI скидання контролера або просідання шини живлення, що впливає на спільний хаб/контролер.

Виправлення: перемістіть критичний пристрій на виділений контролер; додайте PCIe USB-карту; оновіть BIOS; уникайте перевантажених хабів.

3) Зовнішній USB-диск відпадає під час бекаpu

Симптом: Помилки I/O в гості або на хості, потім повторна ініціалізація пристрою; ZFS або бекап падає.

Коренева причина: проблеми з живленням/кабелем; UAS quirks; прошивка enclosure; brownout хаба.

Виправлення: живлений хаб або прямий порт; коротший кабель; розгляньте відключення UAS для enclosure (залежить від пристрою); для серйозних цілей бекапу краще SATA/NVMe.

4) Passthrough працює, доки пристрій не перейде в режим оновлення прошивки

Симптом: Ви прошиваєте донгл; він зникає; повертається з іншим USB ID; ВМ більше не ловить його.

Коренева причина: bootloader показує інший VID:PID і ваше відображення занадто вузьке.

Виправлення: тимчасово передайте за портом; або передайте контролер; або включіть обидва ID, якщо вони відомі.

5) Два однакових донгли міняються місцями після перезавантаження

Симптом: ВМ отримує «не ту паличку» і все ламається тонкими способами.

Коренева причина: відображення за VID:PID без унікального серійного номера; порядок ініціалізації міняється.

Виправлення: прив’яжіть за серійним номером через udev; або використайте прив’язку до фізичного порту; підпишіть кабелі по-європейськи.

6) LXC втрачає пристрій після перепідключення

Симптом: Контейнер мав /dev/ttyUSB0, після перепідключення воно стало /dev/ttyUSB1; апка падає.

Коренева причина: присвоєння ноди змінюється; права контейнера/cgroup не відповідають новій ноді.

Виправлення: створіть стабільний симлінк у /dev/serial/by-id або /dev/serial/by-path; bind-mount стабільний шлях у контейнер; переконайтеся, що cgroup-права дозволяють доступ.

7) «Виправлення» — глобальне вимкнення autosuspend і тепер інші USB поводяться дивно

Симптом: Зростання споживання енергії; деякі пристрої поводяться інакше; мобільні функції енергоощадження втрачені, але ви на сервері.

Коренева причина: застосували глобальний підхід до проблеми, що мала локальний характер.

Виправлення: відкотіть глобальне налаштування; реалізуйте udev-правило для конкретного пристрою; підтвердіть, що runtime_status залишається активним лише для нього.

Контрольні списки / покроковий план

Покроковий план загартування (придатний для продакшену)

1. Зберіть докази: запишіть вивід хоста dmesg -Tw під час хоча б одного відключення; збережіть релевантні рядки з journalctl -k.
2. Підтвердьте топологію: виконайте lsusb -t; зафіксуйте ланцюжок bus/port. Якщо ви не можете описати, куди підключено — не зможете зробити це стабільним.
3. Базове живлення: перемістіть пристрій у задній порт материнської плати; приберіть подовжувачі; перевірте з живленим хабом для донглів.
4. Вимкніть autosuspend для конкретного пристрою: реалізуйте udev-правило для VID:PID (і серійного номера, якщо є). Відключіть та знову підключіть і перевірте, що power/control показує on.
5. Перевірте стабільність під час простою: лишіть пристрій в режимі простою довше за попереднє вікно відмов; переконайтеся в відсутності відключень у journalctl -k.
6. Протестуйте під навантаженням: згенеруйте реалістичний трафік (радіоактивність, диск I/O, опитування UPS). Спостерігайте за скиданнями.
7. Якщо з’являються скидання контролера: зупиніться. Додайте виділений PCIe USB-контролер або ізолюйте через PCI passthrough.
8. Виберіть гранулярність passthrough: пристрій, якщо унікальний і стабільний; порт/шлях, якщо фізично закріплено; контролер для примхливих пристроїв.
9. Закріпіть ідентичність: використовуйте симлінки в /dev/serial/by-id або by-path; уникайте крихких номерів як /dev/ttyUSB0.
10. Запишіть усе: задокументуйте порт, правило та рядок у VM-конфігу. Майбутній ви буде вдячний.
11. Моніторьте: додайте легку перевірку, що сповіщає про повідомлення ядра про відключення або відсутні ноди пристроїв.

Чек-лист відкату (тому що він знадобиться)

• Збережіть копію оригінального /etc/default/grub і файлів udev.
• Впроваджуйте по одному зміненню. Якщо зміните хаб + параметри ядра + режим passthrough одночасно, не знатимете, що виправило проблему.
• Плануйте перезавантаження. Деякі налаштування USB PM потребують перезавантаження для повного застосування; udev-правила — ні.

Три корпоративні історії з передової

Інцидент через неправильне припущення: «воно в ВМ, отже проблема — у ВМ»

У середній компанії команда вела кластер Proxmox, що підтримував кілька «малих але критичних» сервісів. Один із них: ВМ, яка спілкувалася з UPS по USB для коректного вимкнення. Вони передали USB HID до ВМ і перейшли до інших справ.

Через місяці з’явилися спорадичні помилки на стороні ВМ: софт UPS втрачавав пристрій на кілька секунд, потім він знову з’являвся. Команда вирішила, що це проблема драйвера гостя, бо логи ВМ показували симптоми першими. Вони оновлювали ядро гостя, фіксували пакети і навіть міняли софт UPS. Покращень не було.

Під час довшого простою хтось нарешті подивився dmesg на хості під час відтворення. Хост логував відключення USB в ті самі часові мітки. Це була не ВМ. Хост призупиняв пристрій і іноді не вмів його коректно розбудити.

Виправлення було нудним: udev-правило примусово встановило power/control=on для того VID:PID, і пристрій залишився активним. Також вони перемістили кабель UPS на задній порт, подалі від галасливого хаба лабораторії. У звіті про інцидент головна порада була одна: «Завжди доведіть, яке ядро першим зареєструвало відключення».

Оптимізація, що повернулася бумерангом: «енергозбереження скрізь»

В іншій організації хтось дуже захотів заощаджувати енергію. Це був стелаж маленьких серверів в офісі з обмеженим охолодженням. Вони ввімкнули набір енергозберігаючих налаштувань, включно з глибшими C-станами і агресивнішим runtime PM.

USB-перенаправлення почало скочуватися: координатор Zigbee у Home Automation VM відпадав раз на день. Потім зовнішній SSD для щотижневого експорту почав видавати помилки I/O під навантаженням. У лабораторії цього не було; офіс показав це о 2:00 ночі — традиційний час для сюрпризів.

Інженери ганялися за проблемами апки, потім за стеком зберігання, потім за QEMU. Спільним фактором були переходи від простою до навантаження. Autosuspend і runtime PM економили енергію найгіршим можливим способом: вони спали невчасно.

Вони відкотили агресивну поведінку USB покроково, пристрій за пристроєм, а не глобально, і залишили CPU-енергозбереження, оскільки воно не було причетне. Урок не був «енергозбереження — погано». Урок — «енергозбереження потребує винятків для USB-периферії у ваших критичних ланцюгах надійності».

Нудна але правильна практика, що врятувала день: виділені контролери і детермінований розвод кабелів

Фінансова компанія мала Proxmox-хост зі змішаними сервісами, включно з ВМ, що обробляла невеликий HSM по USB. Не мас-маркетний донгл; все одно USB і все одно примхливий.

Вони поводилися з ним як з виробничою залежністю. USB-пристрій жив на виділеному PCIe USB-контролері. Той контролер був переданий до ВМ через PCI passthrough. Фізичний порт був промаркований, кабель короткий і перевірений, а живлений хаб використовували лише там, де він додавав стабільності (не тому що закінчилися порти).

Коли хост пізніше отримав оновлення ядра, кілька неважливих USB-пристроїв на материнці почали іноді скидатися. Нікому це не було важливо. Критичний USB-ланцюг був ізольований. ВМ зберегла свій контролер, свій пристрій і свою стабільність.

Практика була нудною, бо вимагала планування, а не героїчного патчу. Також це означало, що інциденти стосувалися реальної апки, а не питання «чи донгл сьогодні вирішив перевестися».

Поширені запитання

1) Чи варто вимкнути USB autosuspend глобально на Proxmox?

Тільки як короткий діагностичний тест. Якщо це допомагає, реалізуйте per-device udev-правило, яке примусово встановлює power/control=on. Глобальне відключення — грубий інструмент.

2) Чому передача за «Bus 002 Device 008» пізніше провалюється?

Тому що номер «Device 008» присвоюється під час ініціалізації й змінюється після відключення/скидання. Використовуйте VID:PID, серійний номер, by-path або передавайте весь контролер.

3) Мій Zigbee/Z-Wave стік скидається, якщо я підключаю його до USB 3 порту. Чому?

Порти USB 3 можуть бути електрично «шумніші» і по-іншому ділитися хабами. Деякі радіо на 2.4 ГГц чутливі до інтерференції, і деяким донглам краще на USB 2. Використайте USB 2 подовжувач або живлений хаб, щоб віддалити його від хоста.

4) Чи завжди PCI passthrough USB-контролера кращий?

За частою практикою це найстабільніше, але не завжди найзручніше. Ви втрачаєте гнучкість (хост не зможе використовувати порти) і ускладнюєте міграції. Використовуйте, коли passthrough на рівні пристрою постійно ламається.

5) Як зрозуміти, що це живлення, а не керування живленням Linux?

Проблеми з живленням корелюються з навантаженням і можуть впливати на кілька пристроїв; autosuspend корелюється з часом простою і показує runtime_status=suspended. Логи та час подій розкажуть історію.

6) Чому LXC втрачає /dev/ttyUSB0 після перепідключення?

Бо ядро може переназначити ноду як /dev/ttyUSB1 тощо. Використовуйте стабільні симлінки в /dev/serial/by-id або by-path і bind-mount їх у контейнер.

7) Чи можуть хаби спричиняти відключення, навіть якщо пристрій споживає дуже мало енергії?

Так. Хаби можуть бути нестабільні через слабку регуляцію живлення, баги прошивки або проблеми з цілісністю сигналу. Живлений, якісний хаб часто виправляє «таємничі» відключення.

8) Мій пристрій має два різні VID:PID у залежності від режиму. Як обробити passthrough?

Передавайте за фізичним портом/шляхом, щоб повторна ініціалізація все одно була вловлена; або додайте обидва ID; або використайте passthrough контролера під час оновлення прошивки.

9) Це проблема Proxmox чи ядра Linux?

Здебільшого це ні те, ні інше; це апарат, налаштування управління живленням за замовчуванням або поведінка контролера. Proxmox працює на ядрі Linux; журнали хоста — арбітр.

10) Яка найнадійніша конфігурація для «неповинного відпасти» USB-пристрою?

Виділений PCIe USB-контролер, переданий через PCI, відключене autosuspend для цього пристрою на хості (якщо хост торкається його), короткий відомий-добрий кабель і детермінована маркування портів.

Висновок: наступні кроки, що працюють

Якщо ви боретеся з відключеннями USB-перенаправлення в Proxmox, не починайте з екзотичних прапорів ядра. Почніть із доказів, потім застосуйте виправлення, що переживуть перезавантаження й оновлення.

1. Доведіть, де відключення відбувається: dmesg -Tw на хості — ваше перше джерело правди.
2. Стабілізуйте фізичний шар: задній порт, хороший кабель, живлений хаб за потреби.
3. Вимкніть autosuspend для конкретного пристрою через udev-правило; перевірте power/control та runtime_status.
4. Якщо контролер скидається: ізолюйте його виділеним PCIe USB-контролером і розгляньте PCI passthrough.
5. Зробіть ідентичність детермінованою: serial/by-id/by-path, а не нумерацію tty.
6. Документуйте і моніторьте: найкраще виправлення — те, яке ви в змозі пояснити під час інциденту о 3 ранку.

USB може бути стабільним у гіпервізорі. Воно просто потребує того самого ставлення, яке ви даєте дискам і мережі: чисте живлення, детермінована проводка і конфігурації, які припускають, що пристрій зрештою поведе себе неідеально.