Proxmox: збій PCI passthrough — групи IOMMU і класичні пастки

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

Якщо ви на виклику і VM не стартує після увімкнення passthrough, вам не потрібна філософія. Потрібно швидко знайти вузьке місце.
Ось короткий план, який я використовую в продакшні, у порядку, що дає найбільше інформації за мінімум зусиль.

1) Підтвердіть, що IOMMU дійсно ввімкнено (BIOS + ядро)

Більшість заяв про «VFIO не працює» — це «IOMMU ніколи не був увімкнений». Або воно увімкнене в BIOS, але вимкнене в ядрі, або навпаки.
Перевірте журнали ядра і активний командний рядок спочатку; не гадати.

2) Перевірте IOMMU групу цільового пристрою

Якщо GPU ділить групу з SATA-контролером, це вже не «поправимо потім». Це проблема.
Рано вирішіть, чи можете ви прийняти передачу всієї групи, чи можна застосувати ACS override, або потрібне інше обладнання.

3) Перевірте, хто зараз володіє пристроєм

Якщо хост використовує GPU для виводу консолі, або NIC зайнятий модулем ядра, VM не зможе його отримати.
Пов’яжіть до vfio-pci і занотуйте в чорний список конфліктний драйвер. Перевірте за допомогою lspci -k.

4) Перевірте конфігурацію VM, що мовчки саботує вас

Тип машини, розмір ROM BAR, вибір основного GPU, UEFI vs SeaBIOS та хитрощі з скиданням викликають 80% «чорних екранів».
Тут варто перестати «пробувати випадкові поради з форумів» і почати робити свідомі вибори.

5) Лише потім: бігайте за вендор-специфічними дивностями

NVIDIA Code 43, баги скидання AMD, альтернативи Intel iGPU GVT і мультифункціональні пристрої реальні — але не заходьте туди, поки
основи не будуть чисті.

Парафразована ідея від Leslie Lamport тут доречна: Парафразована ідея: розподілена система відмовляє через компонент, про існування якого ви навіть не підозрювали. — Leslie Lamport

Групи IOMMU: що це і чому варто хвилюватися

IOMMU — це апаратний кордон, який дозволяє хосту контролювати, як PCIe-пристрої отримують доступ до пам’яті. Без нього passthrough — це фактично
«будь ласка, не DMA-те в мій гіпервізор», що не є моделлю безпеки — скоріше надія та молитви.
З IOMMU ви можете передати пристрій VM і водночас забезпечувати ізоляцію пам’яті.

Групи IOMMU — практичний наслідок топології PCIe. Пристрої за одним і тим же upstream-мостом без належної ізоляції
(ACS: Access Control Services) не можна чисто відділити. Linux групує їх, тобто: якщо ви передаєте один пристрій,
треба вважати, що вся група потенційно може шпигувати або заважати іншим.

Оператори часто неправильно розуміють це дуже специфічно: вони вважають, що групи — це рекомендація. Ні.
Це опис ядра того, яке обладнання можна безпечно ізолювати. Іноді можна «підчистити» через ACS override; іноді не слід.

Три категорії відмов passthrough

• Невдала ізоляція: пристрій у групі з речами, від яких ви не можете відмовитися (наприклад контролер сховища, USB хост, основний NIC).
• Невдала власність: драйвер ядра хосту володіє пристроєм (або сервіси Proxmox), тому VFIO не може його прив’язати.
• Невдала робота в runtime: VM стартує, але пристрій не ініціалізується (проблеми скидання, ROM-квірки, невідповідність прошивки, розмір BAR, виявлення драйвером GPU).

Ставте ці категорії як дерево рішень. Не «йдіть по колу в налаштуваннях», не знаючи, в якій ви категорії.

Жарт №1: групи IOMMU як оргсхеми — все виглядає відокремленим, поки ви не спробуєте пересунути одну людину і не виявите, що три команди падають.

Факти й історія, що пояснюють сучасні проблеми

Ви можете працювати з passthrough, не знаючи історії, але її знання допоможе передбачити, які платформи поводитимуться добре, а які — будуть вас водити за ніс.
Ось конкретні пункти, що мають оперативне значення.

1. VT-d (Intel) і AMD-Vi (AMD) з’явилися як «верси для DMA» віртуалізації, а не як версії для обчислень. CPU-віртуалізація (VT-x/AMD-V) недостатня для PCI passthrough.
2. Ранні споживчі чіпсети часто реалізовували IOMMU погано або з обмеженою ізоляцією; серверні платформи перші робили це правильно.
3. PCIe ACS стала ланцюговим механізмом для розділення груп; багато споживчих платок опускають ACS на downstream-портах, створюючи великі групи.
4. VFIO замінив старі методи прив’язки пристроїв (історично KVM використовував різні механізми). VFIO стандартизував безпечний доступ до пристроїв і це сучасний базис.
5. GPU passthrough зростав у тіні політик вендорів; драйвери іноді поводилися інакше в VM, і спільнота робила обхідні шляхи.
6. Прийняття UEFI змінило спосіб завантаження option ROM і як GPU ініціалізується. Багато «чорних екранів» — це насправді невідповідність в ланцюжку прошивки/завантаження.
7. Resizable BAR корисний для продуктивності на залізі, але може ускладнити passthrough і відображення BAR у VM залежно від платформи й прошивки.
8. Сучасні ядра посилюють безпеку; те, що «працювало» з більш лояльними дефолтами раніше, тепер може вимагати явних прапорів (і це добре).
9. Патчі ACS override стали популярними саме тому, що екосистема заліза не пріоритезувала чисту ізоляцію для ентузіастів — корисно, але це компроміс.

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

Мета тут не в тому, щоб просто вивалити команди. Кожна команда повинна заробити: запустіть її, інтерпретуйте вивід і потім прийміть рішення.
Приклади для хоста припускають Debian-подібний сервер Proxmox.

Завдання 1: Підтвердіть віртуалізаційні можливості CPU та IOMMU

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|Vendor ID'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU E-2246G @ 3.60GHz
Virtualization:        VT-x

Що це означає: VT-x/AMD-V присутній, але це не підтверджує наявність VT-d/AMD-Vi.
Рішення: переходьте до перевірок ядра/IOMMU; не припускайте, що VT-d є лише тому, що VT-x є.

Завдання 2: Перевірте параметри завантаження ядра на предмет IOMMU

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt

Що це означає: intel_iommu=on увімкнює Intel IOMMU; iommu=pt використовує pass-through мапінг для хост-пристроїв (зазвичай знижує накладні витрати).
Рішення: якщо цих прапорів немає, додайте їх і перезавантажтеся перед подальшими діями.

Завдання 3: Перевірте, чи IOMMU дійсно ініціалізувався

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 15
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.112345] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.112678] DMAR: Initialized

Що це означає: ядро бачить і увімкнуло IOMMU.
Рішення: якщо ви не бачите «IOMMU enabled/Initialized», зайдіть у BIOS (VT-d/AMD-Vi) і виправте платформу спочатку.

Завдання 4: Список PCI-пристроїв з ID (запам’ятайте їх)

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]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Що це означає: у вас є ID пристроїв, наприклад 10de:1e87 (GPU) і 10de:10f8 (його аудіо-функція).
Рішення: плануйте передати весь мультифункціональний набір (GPU + audio), якщо немає вагомої причини інакше.

Завдання 5: Друк груп IOMMU (тест «чи можу я ізолювати це?»)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; lspci -nns "$(basename -a $g/devices/*)"; echo; done
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]

Group 7
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]

Group 8
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Що це означає: GPU у гарній маленькій групі з його аудіофункцією — добре.
Рішення: якщо ваш цільовий пристрій ділить групу з критичними пристроями хоста (SATA-контролер, USB-контролер для клавіатури, єдиний NIC),
вам або передати всю групу, або змінити слоти/налаштування BIOS, або використовувати ACS override з розумінням ризиків, або змінити обладнання.

Завдання 6: Визначте, який драйвер зараз володіє пристроєм

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] Device 3751
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: драйвер NVIDIA хоста завантажений; VFIO не може забрати карту без відв’язування/перев’язування.
Рішення: припиніть використання GPU на хості (немає консолі, немає Xorg), при потребі додайте в blacklist драйвер і прив’яжіть до vfio-pci.

Завдання 7: Переконайтеся, що модулі VFIO доступні і завантажені

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   40960  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             372736  0
kvm                  1036288  1 kvm_intel

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

Завдання 8: Прив’яжіть пристрій до vfio-pci використовуючи ID пристроїв

cr0x@server:~$ sudo sh -c 'echo "options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1" > /etc/modprobe.d/vfio.conf'
cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

Що це означає: при наступному завантаженні VFIO захопить функції GPU рано.
Рішення: робіть так, коли хочете, щоб passthrough був стабільним після перезавантажень. Тимчасові трюки з unbind підходять для експериментів, а не для продакшну.

Завдання 9: Додайте в blacklist конфліктні GPU-драйвери (nouveau часто займає місце)

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset
EOF
cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset

Що це означає: ви перешкоджаєте хосту «допомогти» і завантажити драйвер, що забере ваш пристрій для passthrough.
Рішення: забороняйте лише те, що потрібно. Якщо хост потребує GPU для консолі, використайте iGPU або дешеву другу карту, а ту іншу віддавайте в passthrough.

Завдання 10: Оновіть initramfs, щоб раннє прив’язування/blacklist застосувалися

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Що це означає: ваше раннє середовище завантаження тепер містить нові налаштування модулів.
Рішення: якщо пропустити це, ви проведете довгий час, дивлячись на «чомусь» завантажений неправильний драйвер перед монтуванням rootfs.

Завдання 11: Після перезавантаження підтвердіть, що vfio володіє пристроєм

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] Device 3751
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: правильна власність. Зверніть увагу, що «Kernel modules» може перераховувати кандидатів; важливе поле — «driver in use».
Рішення: якщо все ще не vfio-pci, перевірте blacklist, initramfs і чи не використовується пристрій як boot VGA.

Завдання 12: Підтвердіть, що Proxmox/QEMU бачать вузли пристроїв IOMMU

cr0x@server:~$ ls -l /dev/vfio/
total 0
crw------- 1 root root 240,   0 Dec 26 09:12 0
crw------- 1 root root 240,   7 Dec 26 09:12 7
crw------- 1 root root 240, 255 Dec 26 09:12 vfio

Що це означає: вузли груп існують (тут присутня група 7).
Рішення: якщо вузол групи відсутній, ваші IOMMU-групи не активні або ядро не експонує VFIO коректно.

Завдання 13: Перевірте, чи пристрій підтримує чисте скидання (поширена пастка для GPU)

cr0x@server:~$ sudo dmesg | egrep -i 'vfio|reset|FLR|D3' | tail -n 20
[  112.334455] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  112.334890] vfio-pci 0000:01:00.0: not capable of FLR, device reset may be unreliable

Що це означає: відсутній Function Level Reset (FLR). Це часто виглядає як «працює один раз, потім падає при перезавантаженні VM», бо пристрій не скидається.
Рішення: плануйте відповідно: перезавантажуйте хост між запусками VM, використовуйте вендорні модулі скидання, якщо доречно, або обирайте обладнання з надійним скиданням.

Завдання 14: Перевірте конфіг VM щодо PCIe і OVMF (qm config Proxmox)

cr0x@server:~$ qm config 110
agent: 1
bios: ovmf
boot: order=scsi0;ide2;net0
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-110-disk-0,size=200G
hostpci0: 01:00.0,pcie=1,x-vga=1
hostpci1: 01:00.1,pcie=1
efidisk0: local-lvm:vm-110-disk-1,size=1M,efitype=4m,pre-enrolled-keys=1

Що це означає: це розумна базова конфігурація для багатьох GPU: q35 + OVMF + pcie=1 і x-vga=1 для основного GPU.
Рішення: якщо ви використовуєте i440fx для сучасного GPU і бачите дивності, перейдіть на q35, якщо немає конкретної причини не робити цього.

Завдання 15: Якщо VM не стартує, читайте реальну помилку в логах QEMU

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
cr0x@server:~$ journalctl -u pvedaemon -n 80 --no-pager
Dec 26 09:20:11 server pvedaemon[1324]: start VM 110: UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
Dec 26 09:20:11 server pvedaemon[1324]: VM 110 qmp command failed - unable to open /dev/vfio/7: Device or resource busy

Що це означає: «busy» зазвичай означає проблему власності або завислий процес.
Рішення: знайдіть, хто тримає VFIO групу, і зупиніть його коректно (або зупиніть VM, що вже її використовує).

Завдання 16: Знайдіть процес, що тримає пристрій/групу

cr0x@server:~$ sudo lsof /dev/vfio/7
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 991 root   25u   CHR  240,7      0t0  165 /dev/vfio/7

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

Завдання 17: Проаналізуйте топологію PCIe, щоб зрозуміти проблеми групування

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           |            \-00.1
           \-02.0-[02]----00.0

Що це означає: GPU розташований за шиною 01; NVMe за шиною 02. Чиста сегрегація часто означає чисті групи.
Рішення: якщо все сидить під одним downstream-портом, очікуйте заплутані групи. Розгляньте переміщення карт у інші слоти (підключені до різних root-портів).

Завдання 18: Якщо потрібно, протестуйте ACS override і подивіться, які групи стануть (усвідомлені ризики)

cr0x@server:~$ sudo sed -i 's/quiet/quiet pcie_acs_override=downstream,multifunction/' /etc/default/grub
cr0x@server:~$ grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_acs_override=downstream,multifunction intel_iommu=on iommu=pt"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Що це означає: ви просите ядро удавати, що ACS-ізоляція присутня там, де її може не бути.
Рішення: використовуйте це лише якщо приймаєте компроміс по безпеці/ізоляції. У багатокористувацьких або відповідних до комплаєнсу середовищах уникайте цього.

Жарт №2: ACS override — як зняти стрічку «не заходити», бо вона гальмує, — поки не згадаєш, навіщо стрічка була.

Три корпоративні міні-історії з поля бою

Міні-історія 1: Інцидент через неправильне припущення

Команда впровадила вузли Proxmox для хостингу Windows VM з апаратним прискоренням GPU для бізнес-підрозділу, який потребував легасі-додатка з GPU-рендерингом.
Вони тестували на одній «золотій» робочій станції і все працювало. Закупівля потім взяла іншу ревізію матплати, бо вона була «еквівалентною».
Слово «еквівалентний» у інфраструктурі небезпечне.

На нових платах група IOMMU GPU також містила USB-контролер і вбудоване аудіо. Команда припустила:
«Ми передаємо тільки GPU, тож USB-контролер не повинен мати значення.» Вони ввімкнули ACS override, щоб розділити групи,
похлопали себе по плечу і відправили в продакшн.

Через тижні випадкові VM почали зависати під високим навантаженням. Не падали — зависали. Хост залишався в строю, але процеси QEMU переходили у стани,
які вимагали примусового вбивства. Частота зависань підвищувалася при більшій USB-активності: смарт-картки, USB-камери, дивні периферії.
Напевно ви вже розумієте, куди це веде.

«Розділені» IOMMU групи не були реальною ізоляцією; це були програмно накладені межі. При навантаженні пристрої, що ділили один фізичний шлях,
все ще взаємодіяли способом, який VFIO не міг повністю контролювати. Наслідок не був чистим порушенням безпеки; це був операційний кошмар:
ненадійні скидання, нестабільні переривання і зависання VM, що виглядали як проблеми драйвера.

Виправлення було нудним: вони перейшли на плати з реальною ACS-ізоляцією на root-портах PCIe і припинили ігнорувати реальність.
Ключовий рядок постмортему: припущення, що групи IOMMU — «лише групування Linux», а не «апаратні контейнери». Це речення ймовірно врятувало їх від року повторних інцидентів.

Міні-історія 2: Оптимізація, що відкотилася

Інша організація хотіла вичавити продуктивність. Вони прочитали, що iommu=pt знижує накладні витрати для хост-пристроїв, тож додали його скрізь.
Потім пішли далі: налаштували параметри ядра, переналаштували переривання і встановили агресивні енергозберігаючі налаштування в BIOS, бо енергетична ефективність добре виглядала в презентації.

Passthrough працював — в більшості випадків. Але після технічних вікон частина VM запускалася без GPU, або NIC, переданий firewall VM, втрачав лінк, доки VM не перезавантажили.
Команда вважала це «тимчасовою апаратною дивиною».
Саме такими словами відмови переводяться у повторні відмови.

Причиною виявилося поєднання енергозбереження (пристрої переходили в глибші D-стани), поведінки прошивки і можливостей скидання.
Деякі пристрої не терпіли нові дефолти; інші потребували явної обробки скидання. Оптимізація не була загально неправильною,
вона була неправильною для їхньої конкретної мішанини пристроїв і політик доступності.

Вони відкочували енергозберігаючі фічі PCIe, припинили ганятися за мікрооптимізаціями без вимірів і задокументували правило:
production passthrough вузли отримують консервативні PCIe power налаштування і лише перевірені параметри ядра.
Продуктивність трохи постраждала, але надійність зросла кардинально — а це платить вашу зарплату в довгостроковій перспективі.

Міні-історія 3: Сумна, але правильна практика, що врятувала день

Невелика команда платформи керувала флотом Proxmox вузлів з мішаними навантаженнями. Деякі VM використовували passthrough NIC, інші — GPU.
Їхня практика була надто нудна: на кожному вузлі був нотатник «топологія обладнання», оновлений після будь-якої фізичної зміни — карти слотів, IOMMU групи
і які VM споживають які групи.

Одного вікенду вузол впав і технік замінив його на запасний шасі, швидко перемістивши карти, щоб відновити сервіс.
VM піднялися, але storage VM, що використовував переданий HBA, почав викидати помилки, а інша VM з passthrough NIC не стартувала взагалі.

Замість експериментів у продакшні вони витягли нотатку з топологією. Вона показала, що на запасному шасі HBA і NIC опинилися в одній групі.
Це не була проблема конфігурації Linux; це була невідповідність слота/топології. Вони вимкнули вузол, перемістили одну карту у правильний слот
і відновили сервіси без довготривалого простою.

Ніяких геройств. Ніяких патчів ядра. Жодного сліпого ACS override. Просто документація і дисципліноване відстеження «цей PCIe слот веде до цього root-порту
і цієї IOMMU групи». Практика була настільки нудною, що ніхто не хотів її робити — поки вона не врятувала вихідні і репутацію.

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

1) VM не стартує: «unable to open /dev/vfio/X: Device or resource busy»

Корінь проблеми: процес вже тримає VFIO групу (інша VM, завислий QEMU або залишковий стан прив’язки).

Виправлення: знайдіть тримача за допомогою lsof /dev/vfio/X, зупиніть VM-власника і приберіть застарілі QEMU-процеси. Підтвердіть унікальність власності групи.

2) VM стартує, але GPU показує чорний екран

Корінь проблеми: неправильна прошивка/тип машини VM (SeaBIOS vs OVMF, i440fx vs q35), відсутній ROM GPU або GPU не вказано як primary.

Виправлення: використовуйте bios: ovmf, machine: q35, hostpci0: ...,pcie=1,x-vga=1. Переконайтеся, що передаєте всі функції (GPU audio).

3) GPU працює один раз, потім ламається після перезавантаження VM

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

Виправлення: віддавайте перевагу обладнанню з FLR; інакше плануйте операційно (перезавантаження хоста для чистого скидання) або використовуйте модулі-обхідні рішення, де доречно.

4) Пристрій не прив’язується до vfio-pci; драйвер хоста продовжує його забирати

Корінь проблеми: драйвер завантажується в initramfs до того, як vfio-pci встигне захопити пристрій; blacklists не застосовано рано.

Виправлення: налаштуйте /etc/modprobe.d/vfio.conf + файл blacklist, потім update-initramfs -u. Перезавантажте і перевірте lspci -k.

5) IOMMU групи величезні; GPU ділить групу з SATA/USB/NIC

Корінь проблеми: топологія PCIe материнської плати і відсутність ACS-ізоляції; іноді налаштування BIOS лише погіршують ситуацію.

Виправлення: спробуйте інші слоти, вимкніть «above 4G decoding» тільки якщо це реально змінює групи (часто треба щоб воно було увімкнено), розгляньте іншу плату.
Використовуйте ACS override лише коли погоджуєтесь на зниження ізоляції.

6) Windows VM показує помилку GPU (наприклад драйвер не завантажується, пристрій відключений)

Корінь проблеми: невідповідність конфігурації VM (primary GPU), відсутній UEFI або виявлення вендором/драйвером, що це віртуальне середовище.

Виправлення: виправте конфіг q35/OVMF спочатку; потім вирішуйте вендор-специфічні питання, якщо вони залишаються.

7) Передана NIC раптово втрачає лінк

Корінь проблеми: стани енергозбереження, особливості перенаправлення переривань або ненадійне скидання на цій NIC/слоті.

Виправлення: встановіть консервативні PCIe power налаштування в BIOS, оновіть прошивку і перевірте журнали remapping переривань. Розгляньте переміщення в інший слот/root-порт.

8) Хост Proxmox стає нестабільним при увімкненому ACS override

Корінь проблеми: ви розділили групи програмно, які не ізольовані в залізі; DMA/переривальні шляхи все ще конфліктують.

Виправлення: вимкніть ACS override, переробіть топологію заліза або передавайте цілі групи (і прийміть втрату цих пристроїв для хоста).

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

Покроково: підніміть passthrough без драм

1. Спочатку BIOS: увімкніть VT-d (Intel) або AMD-Vi (AMD). Вимкніть CSM, якщо можете, і тримайте PCIe power management консервативним.
2. Прапори ядра: встановіть intel_iommu=on iommu=pt (або amd_iommu=on iommu=pt) у завантажувачі.
3. Перевірте ініціалізацію IOMMU: гляньте dmesg на предмет «IOMMU enabled/Initialized».
4. Змітьте цільовий пристрій: зафіксуйте його PCI-адресу та ID пристроїв через lspci -nn.
5. Проінспектуйте групи IOMMU: якщо група містить те, що ви не можете втратити, зупиніться і переробіть (зміна слота або заміна обладнання).
6. Прив’яжіть до vfio-pci: додайте options vfio-pci ids=... і занотуйте в blacklist конфліктні драйвери.
7. Оновіть initramfs і перезавантажте: зробіть раннє прив’язування реальним.
8. Підтвердіть прив’язку: lspci -k має показати Kernel driver in use: vfio-pci.
9. Сконфігуруйте VM свідомо: q35 + OVMF для сучасних GPU, включіть всі функції, встановіть pcie=1.
10. Перевірте логи: якщо щось ламається, читайте логи QEMU/daemon; не робіть припущень.
11. Протестуйте цикли перезавантажень: не лише «воно завантажилось один раз», а «витримує перезавантаження гостьової ОС, shutdown/start і політики міграції».
12. Документуйте топологію: зафіксуйте слот → PCI-адреса → IOMMU група → яка VM споживає групу. Майбутній ви скаже дякую сьогоднішньому ви.

Операційний чекліст: перед тим як оголосити «готово для продакшну»

• Хост завантажується без потреби в passthrough GPU для консолі (або має окремий консольний GPU/iGPU).
• Всі пристрої у IOMMU групі або передані разом, або безпечно не використовуються хостом.
• VM витримує 10+ циклів старт/стоп і принаймні 3 перезавантаження гостьової ОС без втрати пристрою.
• Оновлення ядра хоста мають план відкату (і ви протестували VFIO після принаймні одного оновлення).
• Ніякого ACS override у середовищах, що вимагають сильної ізоляції (багатокористувацькі, комплаєнс, модель загрози).
• Ви можете описати область впливу в одному реченні: «Якщо група 7 ламається, це впливає лише VM 110 і ні на що інше.»

FAQ

1) Чому мій GPU треба передавати разом з його аудіо-пристроєм?

Тому що це зазвичай мультифункційний PCI-пристрій: функція GPU на 01:00.0 і HDMI/DP аудіо на 01:00.1.
Вони часто ділять ініціалізацію і поведінку скидання. Передавайте обидві функції, якщо у вас немає протестованої причини не робити цього.

2) Чи «безпечно» використовувати ACS override?

«Безпечно» залежить від вашої моделі загроз. ACS override може змусити Linux показувати менші групи, але не може додати відсутню апаратну ізоляцію.
Для домашньої лабораторії це часто прийнятно. Для середовищ, що вимагають суворої DMA-ізоляції, уникайте цього і виправляйте топологію залізом.

3) У моїй IOMMU групі є SATA-контролер. Що робити?

Не передавайте цю групу, якщо не готові втратити доступ хоста до сховища. Спробуйте інший слот PCIe, перевірте опції BIOS
або переходьте на материнську плату/CPU платформу з кращою ізоляцією root-портів.

4) Чому Proxmox каже, що VFIO-пристрій зайнятий, коли ніяка VM не працює?

Часто це застряглий процес QEMU, завдання управління, що ще тримає пристрій, або частково запущена VM.
Використайте lsof /dev/vfio/X, щоб знайти процес. Потім зупиніть VM коректно або вбийте застряглий процес і перегляньте логи.

5) Використовувати q35 чи i440fx для passthrough?

Для сучасних GPU і PCIe-пристроїв використовуйте q35. Воно моделює PCIe природніше і уникне деяких спадкових дивностей.
Використовуйте i440fx тільки якщо у вас є легасі-залежність гостя або конкретна сумісність.

6) Чи потрібен OVMF (UEFI) для GPU passthrough?

Не завжди, але часто. Багато сучасних GPU і налаштувань Windows 11 працюють краще з OVMF.
Якщо ви бачите чорні екрани або проблеми ініціалізації, переключення на OVMF — зміна з високою віддачею.

7) Що означає «not capable of FLR»?

FLR — це стандартизований механізм скидання. Без нього пристрій може не перезавантажуватися чисто між запусками VM.
Симптоми включають «працює один раз» і «ламається після перезавантаження». Операційне виправлення може бути радикальним, як перезавантаження хоста між запусками, або реальним — зміна обладнання.

8) Чи можна передати пристрої у контейнери (LXC) замість VM?

Частковий доступ до пристроїв можна надати контейнерам, але справжній PCI passthrough — це історія VM, бо потрібна апаратна ізоляція і поведінка VFIO.
Якщо потрібне сильне розмежування і повний контроль над пристроєм, використовуйте VM.

9) Чому групи IOMMU змінюються після оновлення BIOS?

BIOS-оновлення можуть змінити маршрутизацію PCIe, експозицію ACS і спосіб, як мости нумеруються. Це може переформувати групи.
Розглядайте оновлення BIOS як зміну, яку потрібно валідувати для вузлів з passthrough, а не як «рутинне патчування».

10) Чи можна передавати USB-контролер замість окремих USB-пристроїв?

Так, і це часто надійніше для USB-насичених робочих навантажень (донгли, камери, смарт-картки).
Але перевірте його IOMMU групу уважно; USB-контролери часто ділять групи з іншими чипсетними пристроями.

Висновок: подальші кроки, які дійсно рухають вперед

Коли PCI passthrough ламається в Proxmox, найшвидший шлях — перестати вважати це магією і почати розглядати як топологію + власність + прошивку.
Перевірте ініціалізацію IOMMU, прочитайте групи, прив’яжіть пристрої до VFIO рано і налаштуйте VM свідомо (q35 + OVMF — дефолтна позиція для сучасних GPU).

Практичні подальші кроки:

• Зробіть дамп груп IOMMU і збережіть його разом з документацією вузла. Ставтесь до нього як до схеми проводки.
• Після кожного оновлення ядра і після зміни BIOS перевіряйте прив’язку за допомогою lspci -k.
• Якщо ви покладаєтесь на ACS override в чомусь, схожому на продакшн, заплануйте міграцію обладнання/топології. Це технічний борг з гострим зрізом PCIe.
• Тестуйте цикли перезавантажень, а не лише «перший запуск». Більшість відмов пов’язані зі скиданням і життєвим циклом.

Passthrough не складний через Linux. Він складний через апарат. І апарат дуже впевнений у собі.
Узгодьтеся з залізом, і Proxmox стане нудним. Нудьга — це мета.