Несправності при PCI passthrough рідко оголошують себе чемно. Вони з’являються як ВМ, що завантажується лише в чорний екран, мережевий адаптер, що зникає під навантаженням, або хост, який зависає саме під час демо. Тоді всі вказують на VFIO, наче це антагоніст у суботньому мультфільмі.
Зазвичай VFIO виконує свою роботу: відмовляється робити те, що небезпечно або неможливо. Справжній ворог — зазвичай одна з дванадцяти нудних передумов — перемикачі в прошивці, групування IOMMU, поведінка скидання, маршрутизація переривань або той «тимчасовий» параметр ядра, який ви забули додати три місяці тому.
Швидкий план діагностики
Якщо ви на виклику — не починайте з філософії. Почніть з циклу триажу, що відповідає на три питання: (1) чи дійсно IOMMU піднявся, (2) чи ізольовано пристрій, і (3) чи його можна чисто скинути між стартами ВМ?
Перше: підтвердіть, що платформа придатна і IOMMU увімкнено
- Перемикачі BIOS/UEFI: Intel VT-d або AMD-Vi, і бажано «Above 4G decoding» для сучасних GPU і HBA.
- Ядро бачить IOMMU: перевірте dmesg на наявність рядків DMAR/AMD-Vi.
Друге: підтвердіть, що групування IOMMU адекватне
- Перелічіть групи IOMMU і переконайтеся, що пристрій не «склеєний» із вашим SATA-контролером, USB-контролером або кореневим портом чипсета, від якого ви не готові відмовитися.
- Якщо ви покладаєтеся на ACS override — розглядайте це як останній засіб і компроміс у питаннях безпеки, а не як «виправлення».
Третє: підтвердіть прив’язку до VFIO та поведінку скидання
- Переконайтеся, що пристрій прив’язано до
vfio-pciна хості, а не до драйвера вендора. - Перевірте підтримку FLR і особливості скидання (особливо для GPU).
Далі: перевірте бік ВМ (тип машини, UEFI/OVMF, ROM-особливості)
- Виберіть стабільний тип машини QEMU і не поєднуйте практики епохи SeaBIOS з пристроями епохи OVMF.
- Якщо це GPU — вирішіть заздалегідь, чи потрібен вам дампований VBIOS і чи потрібно передавати функцію аудіо теж.
Цей порядок здається очевидним, поки ви не бачите, як хтось дві години підганяє аргументи QEMU, коли в BIOS було відключено VT-d. Це підводить до єдиного закону passthrough: він карає припущення з відсотками.
Короткі факти та контекст (щоб припинити гадати)
- Факт 1: Маркетингова назва IOMMU у Intel — VT-d; у AMD — AMD-Vi. Вони вирішують той самий клас проблем: ізоляцію DMA та ремапінг.
- Факт 2: VFIO не завжди був стандартним підходом. Старіший метод pci-stub існував, але VFIO приніс чистішу, безпечнішу структуру для призначення пристроїв у Linux.
- Факт 3: Групи IOMMU — це не «лялька Linux». Це апаратна/топологічна реальність, виявлена через ACPI і можливості PCIe. Linux — лише посланець.
- Факт 4: ACS (Access Control Services) — це функція PCIe, що може покращити ізоляцію. Багато споживчих плат реалізують її частково або «креативно» — часто у спосіб, який ви не захочете в продакшені.
- Факт 5: «Above 4G decoding» важливий, тому що великі BAR (Base Address Registers) на GPU і сучасних пристроях не вміщуються коректно в старий 32-бітний простір адрес.
- Факт 6: Проблеми скидання GPU — це не міф. Деякі GPU не скидаються повністю без Function Level Reset (FLR) або вендор-специфічної процедури, і хост може не змогти їх ініціалізувати після вимкнення ВМ.
- Факт 7: SR-IOV не з’явився, щоб полегшити ваше життя. Він існує, щоб розділити фізичну PCIe-функцію на віртуальні функції, але множить способи неправильної конфігурації прошивки, драйверів і ізоляції.
- Факт 8: MSI/MSI-X переривання були великим кроком у продуктивності та стабільності порівняно з лінійними перериваннями — і джерелом проблем, коли remapping переривань увімкнено неправильно.
- Факт 9: Proxmox — це «просто Debian з думкою», що добре: більшість налагодження — це стандартні інструменти Linux, коли ви припините вважати інтерфейс магією.
Цитата, яку я тримаю на ментальній панелі: парафразована думка
— В. Едвардс Демінг, про покращення систем через покращення процесу, а не крик на результати. У світі passthrough ваш «процес» — це цикл перевірок нижче.
Чекліст / покроковий план (12+ перевірок з командами)
Тут припиняється «спробувати щось» і починається збір доказів. Кожне завдання містить: команду, що означає її вивід, і рішення, яке ви приймаєте.
1) Визначте точні PCI-пристрої та функції, які ви хочете передати
cr0x@server:~$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]
03:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521]Що це означає: Потрібні BDF (bus:device.function) та vendor:device ID. GPU часто мають кілька функцій (VGA + audio). NIC-и можуть мати кілька портів/функцій теж.
Рішення: Запишіть повний набір функцій, які треба передати разом. Якщо ви передасте 01:00.0, але забудете 01:00.1, пізніше виникне дивна поведінка і ви звинуватите QEMU через помилки в обліку.
2) Перевірте флаги віртуалізації процесора (не пропускайте, бо «це сервер»)
cr0x@server:~$ lscpu | egrep -i 'Virtualization|Flags'
Virtualization: VT-x
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpidЩо це означає: VT-x/AMD-V — для запуску ВМ; це не VT-d/AMD-Vi. Якщо цього немає, ви вправі налагоджувати не ту підсистему.
Рішення: Якщо віртуалізація відсутня — зупиніться. Виправте BIOS/UEFI перш ніж продовжувати. Якщо це орендована машина, підтвердіть, що це не SKU, ворожий до віртуалізації.
3) Підтвердіть, що IOMMU увімкнено у прошивці і дійсно активне в Linux
cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 30
[ 0.000000] DMAR: IOMMU enabled
[ 0.000000] DMAR: Host address width 39
[ 0.084123] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[ 0.084129] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c90780106f0462 ecap f020de
[ 0.251990] DMAR: Intel(R) Virtualization Technology for Directed I/OЩо це означає: Ви хочете бачити «IOMMU enabled» і щоб це з’явилося рано в процесі завантаження. Якщо ви бачите помилки про remapping переривань або «no IOMMU found», сьогодні про passthrough іти мова не буде.
Рішення: Якщо IOMMU не увімкнено — перевірте перемикачі BIOS (VT-d/AMD-Vi) і наступним кроком перевірте параметри командного рядка ядра.
4) Перевірте параметри командного рядка ядра (щоб не саботувати себе)
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-5-pve root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunctionЩо це означає: intel_iommu=on (або amd_iommu=on) увімкне IOMMU. iommu=pt використовує режим passthrough для пристроїв хоста заради продуктивності; це звично і зазвичай ок.
Рішення: Якщо ви бачите intel_iommu=off або відсутні параметри IOMMU та dmesg мовчить — виправте конфігурацію GRUB/systemd-boot і перезавантажтеся. Якщо ви бачите pcie_acs_override — розглядайте це як «ми порушуємо правила».
5) Підтвердіть, що remapping переривань увімкнено (стабільність під навантаженням тут)
cr0x@server:~$ dmesg | egrep -i 'remapping|x2apic|irq' | head -n 50
[ 0.000000] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 0.000000] x2apic enabledЩо це означає: IRQ remapping — це функція безпеки й коректності. Без неї деякі пристрої й MSI-переривання можуть поводитися як будинок з привидами під навантаженням.
Рішення: Якщо IRQ remapping не увімкнено — знову перевірте BIOS на наявність «Interrupt Remapping» або споріднених опцій віртуалізації. На деяких платформах винна застаріла прошивка.
6) Огляньте групи IOMMU (це вирішує, що можна безпечно передавати)
cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "IOMMU Group ${d#*/iommu_groups/*}: $(lspci -nns ${d##*/})"; done | sort -V | sed -n '1,30p'
IOMMU Group 0: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
IOMMU Group 1: 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]
IOMMU Group 12: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
IOMMU Group 12: 01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]
IOMMU Group 13: 03:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521]Що це означає: Пристрої в одній групі можуть виконувати DMA один в одного, якщо платформа не забезпечує коректної ізоляції. Якщо ваш GPU ділить групу з USB-контролером, який потрібен хосту, ви в глухому куті або на межі ризику.
Рішення: Якщо групування чисте — рухайтесь далі. Якщо групування заплутане — розгляньте перевстановлення пристрою в інший слот, зміну налаштувань PCIe в BIOS, оновлення прошивки або — лише якщо ви приймаєте компроміс — використання ACS override.
7) Перевірте, чи пристрій підтримує скидання (FLR) або зафіксуйте, що ні
cr0x@server:~$ lspci -s 01:00.0 -vv | egrep -i 'Capabilities:.*Express|FLR|Reset' -n
12:Capabilities: [60] Express (v2) Endpoint, MSI 00
55: DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- FLR+Що це означає: FLR+ натякає на підтримку Function Level Reset. Це не гарантія гарного життя, але добрий знак. Деякі пристрої (особливо старі GPU) пройдуть через passthrough один раз, а потім зависнуть до перезавантаження хоста.
Рішення: Якщо FLR відсутній і ви бачите повторювані «device is in use» або «failed to reset» проблеми — плануйте експлуатаційно: перезавантаження хоста між призначеннями або підбір іншого обладнання.
Жарт #1: PCI passthrough — це як зустріч з принтером: усе ок, поки вам не потрібно, щоб він справді працював.
8) Переконайтеся, що хост прив’язує пристрій до vfio-pci (а не до nouveau/nvidia/amdgpu)
cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080]
Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [GeForce RTX 2080]
Kernel driver in use: vfio-pci
Kernel modules: nvidiafb, nouveauЩо це означає: «Kernel driver in use» має бути vfio-pci. «Kernel modules» може перераховувати потенційні модулі — це нормально.
Рішення: Якщо драйвер вендора використовується — виправте прив’язку: додайте ID пристроїв до vfio-pci, забороніть конфліктні драйвери, перебудуйте initramfs, перезавантажтеся і перевірте знову.
9) Підтвердіть, що модулі vfio завантажуються і присутні в initramfs
cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci 16384 0
vfio_pci_core 73728 1 vfio_pci
vfio_iommu_type1 45056 0
vfio 45056 2 vfio_pci_core,vfio_iommu_type1
kvm_intel 401408 0
kvm 1343488 1 kvm_intelЩо це означає: Якщо основні модулі VFIO не завантажені — ви не готові. Якщо вони завантажуються тільки після того, як драйвер хоста захопив пристрій, ви можете програти в гонці.
Рішення: Якщо порядок завантаження модулів неправильний — додайте модулі до /etc/modules, переконайтеся в правильних ID для vfio-pci і згенеруйте initramfs ще раз, щоб vfio прив’язувався раніше.
10) Перевірте, чи Proxmox/QEMU дійсно використовує IOMMU в конфігурації ВМ
cr0x@server:~$ qm config 101 | egrep -i 'hostpci|machine|bios|efidisk|args'
bios: ovmf
machine: q35
hostpci0: 01:00,pcie=1,x-vga=1
hostpci1: 01:00.1,pcie=1
efidisk0: local-lvm:vm-101-disk-0,efitype=4m,pre-enrolled-keys=1
args: -cpu hostЩо це означає: Для GPU і багатьох PCIe-пристроїв q35 + pcie=1 — розумний за замовчуванням вибір. Передача і GPU, і його аудіо-функції запобігає напівприкріпленим пристроям. OVMF типовий для сучасних Windows і UEFI Linux гостьових ОС.
Рішення: Якщо ви бачите застарілі типи машин і дивні прапорці з форумних пасток — спростіть. Перейдіть на q35 + OVMF, якщо у вас немає конкретної причини інакше.
11) Перевірте на конкуренцію ресурсів на хості: затримки I/O і CPU steal можуть виглядати як «нестабільність passthrough»
cr0x@server:~$ pveperf
CPU BOGOMIPS: 71999.84
REGEX/SECOND: 6068330
HD SIZE: 76.80 GB (rpool/ROOT/pve-1)
FSYNCS/SECOND: 1098.55
DNS EXT: 55.76 msЩо це означає: FSYNCS/SECOND — груба, але корисна індикація затримки сховища. Якщо вона жахлива, ваші «GPU passthrough підлагування» можуть бути результатом блокування гостьової ОС на диск.
Рішення: Якщо сховище повільне — припиніть налаштовувати VFIO і почніть оптимізувати сховище: перевірте налаштування ZFS sync, стан SLOG, прошивку контролера і глибину черги. Або перемістіть диски ВМ з проблемного пулу.
12) Перевірте hugepages / тиск на відображення IOMMU і наявність пам’яті
cr0x@server:~$ grep -E 'HugePages|AnonHugePages|MemAvailable' /proc/meminfo | head
MemAvailable: 58723452 kB
AnonHugePages: 10240000 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0Що це означає: Якщо ви закріпили hugepages або позбавили хост пам’яті, призначення пристрою може падати в способи, які виглядають не пов’язаними. Деякі конфігурації свідомо використовують hugepages; це нормально. Але треба знати, що ви це зробили.
Рішення: Якщо пам’ять напружена — зменшіть пам’ять ВМ, припиніть overcommit або додайте ОЗП. Якщо потрібні hugepages — налаштуйте їх свідомо й документуйте як дорослі люди.
13) Перевірте використання ACS override і зрозумійте радіус ураження
cr0x@server:~$ grep -R "pcie_acs_override" -n /etc/default/grub /etc/kernel/cmdline 2>/dev/null
/etc/default/grub:6:GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"Що це означає: ACS override може штучно розділяти групи. Воно робить passthrough можливим на споживчих платах, які інакше не ізолювали б пристрої належним чином.
Рішення: Якщо це домашня лабораторія, ви можете прийняти це. Якщо це продакшн з ворожою багатокористувацькою середою або суворою відповідністю — уникайте цього. Краще обладнання дешевше, ніж пояснювати інцидент із DMA-ізоляцією.
14) Перевірте потреби GPU у VBIOS (особливо якщо GPU — первинний)
cr0x@server:~$ dmesg | egrep -i 'vfio|rom|bar|vga' | tail -n 30
[ 12.912345] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[ 12.934567] vfio-pci 0000:01:00.0: BAR 0: assigned [mem 0xf6000000-0xf6ffffff 64bit]
[ 12.945678] vfio-pci 0000:01:00.0: BAR 2: assigned [mem 0xd0000000-0xdfffffff 64bit pref]
[ 13.012345] vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x19@0x900Що це означає: Призначення BAR — нормальне явище. Якщо в гості відсутній вивід, GPU може потребувати ROM-файлу, особливо якщо він використовувався як головний дисплей хоста (прошивка може не надати чистий option ROM).
Рішення: Якщо гостева ОС ніколи не ініціалізує GPU і ви перевірили все інше — спробуйте надати чистий VBIOS ROM і переконайтеся, що ви не боретеся з драйвером консолі хоста.
15) Перевірте NVIDIA Code 43 / відмови драйвера (для Windows-гостей)
cr0x@server:~$ qm showcmd 101 --pretty | egrep -i 'kvm=|hidden|vendor|cpu host' | head -n 50
-cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff
-machine type=q35,accel=kvm
-smbios type=1,uuid=2b4b9a2a-4a1a-4c3c-9f28-8ed0f843b2c1Що це означає: Сучасні драйвери NVIDIA для потреб споживачів інколи виявляли віртуалізацію і відмовлялися працювати в певних випадках. Ситуація змінювалася з часом, але «драйвер відмовляється у ВМ» досі трапляється залежно від GPU, гілки драйвера і конфігурації гостя.
Рішення: Якщо ви побачили симптоми схожі на Code 43 — підтвердіть, що ви використовуєте апаратне прискорення KVM, -cpu host і базові Hyper-V enlightenments. Не починайте з випадкових «приховати KVM» хаки, якщо не маєте конкретного регресу для відтворення.
16) Переконайтеся, що пристрій не використовується хостом (відкриті дескриптори файлів, сервіси або бриджі)
cr0x@server:~$ lsof /dev/vfio/* 2>/dev/null | head
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
qemu-sys 4212 root 25u CHR 246,0 0t0 123 /dev/vfio/12Що це означає: Якщо попередній процес QEMU ще тримає VFIO-групу, ваш наступний старт зазнає невдачі. Це також ловить моменти «ВМ все ще десь працює».
Рішення: Якщо ви бачите застарілий процес — зупиніть його коректно. Якщо він не вмирає — спочатку зберіть логи, потім термінуйте. Іноді перезавантаження — це найменш поганий варіант при завислому PCIe-пристрої.
17) Підтвердіть стан SR-IOV (якщо ви передаєте VF)
cr0x@server:~$ lspci -s 03:00.0 -vv | egrep -i 'SR-IOV|Virtual Function' -n
210:Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
220: Total VFs: 8, Initial VFs: 0, Number of VFs: 4, Function Dependency Link: 00Що це означає: SR-IOV присутній і налаштований на 4 VFs. Якщо очікувані VFs не з’являються — відсутні налаштування в прошивці, драйвері чи sysfs.
Рішення: Якщо VFs не створюються — увімкніть SR-IOV в BIOS (якщо застосовно), переконайтеся, що драйвер хоста підтримує його, і явно налаштуйте створення VF. Якщо ви змішуєте VFs і PF passthrough — будьте дуже уважні щодо обмежень пристрою.
Три корпоративні міні-історії з передової
Міні-історія 1: інцидент, спричинений неправильним припущенням
Команда успадкувала кластер Proxmox, який «вже робив GPU passthrough». Попередній власник залишив записку: «працює, не чіпайте». Ця записка застаріла як молоко.
Пройшло незначне оновлення: нове ядро, нова прошивка, той самий залізяк. У понеділок зранку render-ВМ почалися, але GPU не підключилися. Дашборд виглядав нормально. Користувачі отримали чорні екрани й голосні версії помилок.
Перший інженер ганявся за аргументами QEMU. Другий ганявся за драйверами Windows. Третій зробив єдине корисне: перевірив IOMMU-групи і помітив, що вони змінилися. GPU тепер був у групі з PCIe-мостом, який також включав USB-контролер, потрібний хосту. Раніше це «працювало», бо стара прошивка по-іншому перераховувала PCIe і групування.
Неправильне припущення було тонким: «групи IOMMU стабільні між оновленнями». Вони не є. Оновлення прошивки, зміни ядра і навіть інша конфігурація слотів можуть перемішати топологію. Це не каприз Linux; це платформа, що відкриває нову інформацію або маршрут.
Виправлення було нудним: перемістити GPU в інший слот, відключити непотрібний вбудований контролер, щоб спростити дерево, і оновити інструкцію з перевіркою груп після зміни прошивки. Інцидент не закінчився героїкою. Він закінчився чеклістом.
Міні-історія 2: оптимізація, що відплатилася
Інша організація хотіла «максимальну продуктивність» для ВМ з низькою затримкою, що використовувала passthrough NIC. Хтось увімкнув усі відомі йому налаштування продуктивності: hugepages, pinning CPU, isolcpus, налаштування irqbalance, агресивні енергозберігаючі опції. Це виглядало вражаюче. Також зробило систему крихкою.
Вона прекрасно працювала тиждень. Потім під час обслуговування перезавантажили хост, і ВМ почала втрачати пакети. NIC passthrough все ще підключався, але трафік мав джиттер і іноді зупинки. На хості розподілення переривань виглядало нерівномірно; одне ядро було перевантажене.
Причина не була у VFIO. «Оптимізована» ізоляція CPU закріпила занадто багато і переривання застрягли на непідходящому наборі ядер після завантаження. Хост виконував додаткову роботу, пересуваючи переривання і обробляючи шум таймерів у дивному кутку планувальника.
Вони відкочували половину налаштувань, залишили тільки вимірювані, і повернули irqbalance з явними правилами афінітету. Синтетичний бенчмаркінг показав невелике падіння продуктивності. У реальному житті затримка покращилася, і система перестала бути скляною скульптурою.
Жарт #2: Кожного разу, коли ви «оптимізуєте» систему без вимірів, переривання йде на найгірше ядро зі злобою.
Міні-історія 3: нудна, але правильна практика, що врятувала ситуацію
Одна команда керувала невеликою флотилією Proxmox-нодів для змішаних навантажень: ВМ з великим навантаженням на сховище та кілька десктопів з GPU passthrough. Нічого фантастичного. Але у них була дисципліна.
Вони зберігали простий артефакт для кожного хоста: текстовий файл з версіями прошивок, командним рядком ядра, переліком IOMMU-груп і призначеними пристроями passthrough. Після будь-якого оновлення BIOS або зміни заліза вони знову робили збір артефактів. Це займало десять хвилин. Люди бурчали. Вони все одно робили це.
Одного дня вузол несподівано перезавантажився після стрибка напруги. Коли він повернувся, одна VM з GPU не стартувала через помилку VFIO group. Інженер на виклику порівняв сьогоднішні IOMMU-групи з останнім відомо-робочим артефактом. GPU тепер ділив групу з SATA-контролером, бо налаштування прошивки відкотилося.
Виправлення було миттєвим: відновити налаштування BIOS, підтвердити IOMMU-групи і перезапустити ВМ. Ніякого гадання, ніякого племінного знання, ніякої «зміни ядра». Нудна практика не зробила нікого знаменитим — в цьому і суть.
Поширені помилки: симптом → корінь → виправлення
Цей розділ існує тому, що ми всі повторюємо ті самі провали, тільки з різними іменами хостів.
1) ВМ не стартує: “failed to set iommu for container” / “no IOMMU detected”
Симптом: QEMU відмовляється стартувати з помилкою IOMMU/VFIO.
Корінь: VT-d/AMD-Vi відключено в BIOS, неправильно вказаний cmdline ядра або завантажено ядро без підтримки IOMMU.
Виправлення: Увімкніть VT-d/AMD-Vi у прошивці, додайте intel_iommu=on або amd_iommu=on, перезавантажтеся, підтвердьте через dmesg.
2) ВМ стартує, але пристрій не видно всередині гостя
Симптом: Гостьова ОС завантажується, але GPU/NIC не з’являються, або з’являються з помилками.
Корінь: Неправильний BDF, відсутня мультифункція (GPU audio), пристрій не прив’язано до vfio-pci або проблема з драйвером гостя.
Виправлення: Перевірте lspci -nn, передайте всі необхідні функції, підтвердіть Kernel driver in use: vfio-pci і перевірте драйвери гостя.
3) Працює раз після завантаження, потім падає до перезавантаження хоста
Симптом: Перший старт ВМ після завантаження хоста працює; наступні старти не вдаються або GPU залишається чорним.
Корінь: Пристрій не має надійного скидання (немає FLR) або є вендор-специфічний збій скидання (поширено для деяких GPU).
Виправлення: Обирайте залізо з підтримкою FLR, спробуйте специфічні модулі ядра/вендора для скидання або прийміть перезавантаження хоста як робочий обходний шлях.
4) Випадкові зависання хоста під навантаженням
Симптом: Хост блокується під важким I/O або GPU-навантаженням, іноді потребуючи вимкнення живлення.
Корінь: Пошкоджений remapping переривань, багова прошивка, нестабільний оверклок або проблеми з живленням PCIe (так, навіть у «серверних» збірках).
Виправлення: Підтвердіть DMAR-IR: Enabled IRQ remapping, оновіть BIOS, відключіть оверклоки, перевірте живлення. Якщо платформа споживча — поводьтеся відповідно.
5) Продуктивність жахлива, хоч passthrough «працює»
Симптом: Низькі FPS, підлагування, стрибки затримки, втрата пакетів або переривчасті паузи.
Корінь: Затримка сховища, конкуренція CPU, неправильна модель CPU або неправильно спрямовані переривання. Passthrough не робить вас невразливими до інших проблем хоста.
Виправлення: Поміряйте: pveperf, iostat, top, розподіл переривань. Виправте вузькі місця перед тим, як чіпати флаги VFIO.
6) Пристрій застряг у IOMMU-групі з «усім»
Симптом: GPU ділить групу з USB/SATA/чипсетними пристроями.
Корінь: Топологія материнської плати не має ACS-ізоляції; пристрій за тим самим root complex; проводка слоту.
Виправлення: Перемістіть слоти, змініть налаштування PCIe в BIOS, оновіть прошивку або прийміть ризик ACS override. Для продакшн-ізоляції оберіть плату, що поводиться відповідально.
Checklists / step-by-step plan
Якщо потрібно щось вставити в тикет, використовуйте цю послідовність. Вона навмисно повторювальна; повторення скорочує час простою.
Базова перевірка хоста (зробіть один раз на вузол, а потім після будь-якого оновлення BIOS)
- Підтвердіть флаги віртуалізації:
lscpuі зафіксуйте вивід. - Підтвердіть IOMMU активним:
dmesg | egrep -i 'DMAR|AMD-Vi|IOMMU'. - Підтвердіть remapping переривань:
dmesg | egrep -i 'DMAR-IR|remapping'. - Збережіть kernel cmdline:
cat /proc/cmdlineі збережіть. - Змініть дамп IOMMU-груп і збережіть як артефакт.
Перевірка на пристрій (кожного разу, коли додаєте пристрій passthrough)
- Запишіть ID пристроїв і функції:
lspci -nn. - Перевірте членство в групі: дамп груп і підтвердіть ізоляцію.
- Перевірте можливість скидання:
lspci -vvі відмітьте FLR. - Прив’яжіть до vfio-pci і підтвердіть через
lspci -k.
Перевірка на ВМ (кожного разу при зміні конфігурації ВМ)
- Підтвердіть тип машини й BIOS:
qm config VMID. - Підтвердіть, що hostpci записи включають усі потрібні функції.
- Підтвердіть режим CPU: віддавайте перевагу
-cpu host, якщо немає суміснісної причини інакше. - У разі невдачі перевірте, хто тримає VFIO-групу:
lsof /dev/vfio/*.
Дві «правила — зупиніться копати»
- Якщо IOMMU не активний у dmesg — перестаньте чіпати аргументи QEMU. Виправте прошивку/командний рядок ядра спочатку.
- Якщо ваша IOMMU-група «брудна» і ви думаєте про ACS override — зупиніться і вирішіть, чи готові ви до ризику. Не йдіть сюди у сні.
Питання й відповіді
1) Чи потрібні обидва VT-x і VT-d (або AMD-V і AMD-Vi)?
VT-x/AMD-V — для віртуалізації CPU. VT-d/AMD-Vi — для IOMMU (ремапінгу DMA) і саме на ньому залежить PCI passthrough. Зазвичай бажано мати обидва.
2) Чи безпечний iommu=pt?
Це поширено і зазвичай безпечно з погляду продуктивності на хостах, де ви не прагнете накладати витрати на трансляцію на не-passthrough пристрої. Воно не замінює правильну ізоляцію; воно лише змінює, як хост використовує IOMMU.
3) Чи варто використовувати ACS override?
Лише якщо ви розумієте наслідки для безпеки й коректності. Воно робить споживче обладнання придатним для домашніх лабораторій. Воно також може створити ізоляцію, яка виглядає реалістично, але не така міцна, як нативна апаратна ACS.
4) Чому моєму GPU потрібно передавати його аудіофункцію?
Багато GPU відкривають HDMI/DP аудіо-контролер як окрему PCI-функцію. Гості поводяться краще, коли обидві функції призначено, і це запобігає тому, що хост прив’яже залишкову функцію.
5) SeaBIOS чи OVMF?
OVMF (UEFI) — сучасний стандарт, особливо для Windows 11 і новіших GPU. SeaBIOS може працювати для старіших гостей, але поєднання старих уявлень з новими GPU — це шлях у «чорний екран».
6) Мій пристрій у тій же IOMMU-групі, що й PCI-мост. Чи це завжди погано?
Не обов’язково. Мости можуть бути частиною топології. Важливо те, чи група включає пристрої, які ви не можете або не повинні передавати разом. Якщо в групі є USB-контролер чипсета, потрібний хосту — це практична проблема.
7) Чому passthrough ламається після оновлення ядра?
Оновлення ядра можуть змінити поведінку драйверів, порядок ініціалізації і навіть як застосовуються кверки. Оновлення прошивки також можуть змінити перерахунок PCIe. Саме тому ви зберігаєте артефакти (cmdline, групи, прив’язки) і перевіряєте після апгрейду.
8) Чи можуть проблеми продуктивності ZFS виглядати як VFIO-проблеми?
Так. Якщо гостьове сховище затримується, ви побачите підлагування, відставання вводу та «випадкові» тайм-аути, які люди приписують GPU або NIC. Перед переписуванням конфігів ВМ виміряйте затримки сховища.
9) Чи потрібно дампити і передавати VBIOS ROM-файл?
Іноді. Це частіше, коли GPU ініціалізується прошивкою хоста як первинний дисплей або коли платформа не надає чистий option ROM гостю. Якщо все інше перевірено і ви все ще маєте чорний екран — це розумний наступний експеримент.
10) Чому хост іноді потребує перезавантаження після зупинки passthrough-ВМ?
Тому що не всі пристрої скидаються надійно. Якщо пристрій не може повернутися до чистого стану, наступне призначення зазнає невдачі. Це не драматизація Proxmox; це залізо, що відмовляється забути, що сталося.
Висновок: наступні кроки, які працюють
Коли passthrough ламається, ваше завдання — не перехитрити VFIO. Ваше завдання — довести, що платформа надає передумови, яких вимагає VFIO: IOMMU увімкнено, чиста ізоляція груп, правильна прив’язка драйверів і пристрій, що скидається, як годиться.
Зробіть наступне:
- Зберігайте по три артефакти на хост:
/proc/cmdline, перелік IOMMU-груп іlspci -kдля passthrough-пристроїв. - Якщо ви використовуєте ACS override — запишіть це як рішення про ризик, а не як налаштування. Вирішіть, чи варто замінити обладнання.
- Перш ніж змінювати аргументи ВМ, перевірте IOMMU і IRQ remapping у dmesg. Якщо вони некоректні — зупиніться і виправте прошивку/командний рядок.
- Для нестабільних пристроїв тестуйте поведінку скидання явно: запустіть ВМ, зупиніть ВМ, запустіть знову — без перезавантаження хоста. Якщо це фейл, вважайте скидання коренем проблеми, поки не доведете протилежне.
Коли ви зможете відтворити помилку з доказами, VFIO перестає бути крайнім винуватцем і стає тим, чим він є: суворим охоронцем, що дотримує правил, які ваша платформа пообіцяла дотримуватися.