Proxmox GPU Passthrough: чорний екран — 10 причин і виправлень

Швидкий план діагностики (перевірити першим/другим/третім)

Якщо екран чорний, не метушіться. Канал passthrough GPU довгий. Ваше завдання — знайти, який сегмент не працює:
ізоляція пристрою на хості, ініціалізація прошивки VM, драйвер гостя або маршрутизація виводу.

Перший крок: підтвердіть, що хост дійсно передав GPU у VFIO

• Перевірте прив’язку: GPU має бути прив’язаний до vfio-pci, а не до nvidia, amdgpu чи nouveau.
• Перевірте, що IOMMU увімкнено: якщо DMA remapping вимкнено, passthrough може працювати частково, а потім падати дивно.
• Перевірте IOMMU групи: якщо GPU в групі з іншими пристроями, які ви не передаєте, будуть непослідовні відмови.

Другий крок: підтвердіть, що VM може ініціалізувати пристрій (прошивка + тип машини)

• OVMF vs SeaBIOS: сучасні GPU часто потребують UEFI (OVMF). Деякі старі карти поводяться краще з SeaBIOS. Обирайте свідомо.
• Q35 vs i440fx: Q35 — за замовчуванням не випадково (PCIe). Багато проблем passthrough зникають на Q35.
• Налаштування первинного GPU: якщо VM очікує пристрій виводу, але ви його прибрали, ви можете дивитися в порожнечу, бо нічого не попросили.

Третій крок: підтвердіть, що драйвер гостя здоровий і вивід правильно маршрутизовано

• Windows: перевірте Device Manager на помилки (Code 43, Code 31) та журнал подій.
• Linux-гості: перевірте dmesg на ініціалізацію amdgpu/nvidia і підтвердіть, який вихід «гарячий».
• Маршрутизація виводу: протестуйте різні порти (DP vs HDMI) та відключіть високі частоти оновлення + HDR під час налагодження.

Одна цитата, яку варто тримати в голові під час налагодження: перефразована ідея Річарда Фейнмана:
«Реальність має перевагу над пресою.» В операційних термінах: довіряйте тому, що каже ядро, а не тому, що підказує UI.

Цікаві факти та коротка історія (чому все так вибагливо)

• Intel VT-d (DMA remapping) з’явився значно пізніше за віртуалізацію CPU; ранні гіпервізори могли запускати VM, але не безпечно передавати пристрої.
• VFIO замінив старіші фреймворки PCI passthrough в Linux, бо він безпечніший і правильно інтегрується з IOMMU.
• OVMF — це, по суті, UEFI-прошивка для VM; оскільки GPU стали більш орієнтованими на UEFI, шляхи legacy BIOS стали частіше давати збої.
• GPU — це не «просто PCIe-пристрої»: багато з них — маленькі комп’ютери з власною прошивкою, тренуванням пам’яті та станом під час завантаження.
• NVIDIA “Code 43” став ритуалом для користувачів passthrough; тепер трапляється рідше, але все ще з’являється в крайніх випадках.
• Баги скидання реальні: деякі GPU не скидаються повністю після вимкнення VM, тож наступне завантаження отримує пристрій у поганому стані.
• ACS (Access Control Services) впливає на ізоляцію PCIe; споживчі плати можуть групувати пристрої разом, навіть коли ви хочете їх розділити.
• Resizable BAR — це функція для продуктивності, що змінює відображення пам’яті; вона корисна, поки не починає створювати проблеми, особливо через межі прошивок.
• Навчання з’єднання DisplayPort може відмовляти після «теплих» перезавантажень; «чорний екран» може бути проблемою переговорів монітора, а не PCI.

Ментальна модель: де виникає чорний екран

«Чорний екран» — це не одна проблема; це симптом. Стек passthrough GPU має шари, і кожен шар може відмовити так, що зі свого місця ви побачите однаковий результат.

1. Апаратна ізоляція: IOMMU має транслювати DMA, а топологія PCIe має дозволяти чисто ізолювати GPU.
2. Прив’язка драйвера на хості: хост не повинен захоплювати GPU нативним драйвером. VFIO має володіти ним до старту VM.
3. Прошивка VM та модель машини: OVMF/Q35 мають перерахувати PCIe, присвоїти BAR і правильно ініціалізувати шляхи option ROM.
4. Драйвер гостя: Windows/Linux мають завантажити драйвер, який впорається з оточенням, управлінням живленням і ініціалізацією дисплея.
5. Відеовихід: GPU може бути справним, але вивід на іншому порті, переговори монітора не пройшли або GPU очікує на mode set.

Сухий-фанний факт: GPU невинний, доки не доведено протилежне, але він все одно зіпсує вам день, як кіт з доступом до клавіатури.

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

Ось завдання, які я виконую приблизно в цьому порядку. Кожне має: команду, що означає її вивід, і яке рішення робити далі.
Вони написані для хоста Proxmox VE (Debian-based).

Завдання 1: підтвердити, що IOMMU дійсно увімкнений

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.012345] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.045678] DMAR: DRHD base: 0x000000fed90000 flags: 0x1

Значення: Ви маєте бачити «IOMMU enabled» (Intel DMAR) або «AMD-Vi: IOMMU enabled».

Рішення: Якщо не бачите — зупиніться. Виправте налаштування BIOS та параметри ядра перед тим, як змінювати конфігурацію VM.

Завдання 2: перевірити параметри 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 iommu=pt

Значення: intel_iommu=on або amd_iommu=on має бути присутнім. iommu=pt часто використовується для продуктивності.

Рішення: Якщо відсутній — редагуйте GRUB, update-grub, перезавантажте. Не «сподівайтеся, що воно нормально».

Завдання 3: ідентифікувати PCI ID GPU (і аудіо-функцію)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display|audio' 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)

Значення: GPU часто мають мультифункціональні інтерфейси. Аудіо-функція важлива для скидання й для стабільності драйверів Windows.

Рішення: Плануйте передавати обидві функції, якщо немає причини не робити цього.

Завдання 4: перевірити, який драйвер наразі «володіє» GPU

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [1462:3751]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Значення: «Kernel driver in use: vfio-pci» — це те, що вам потрібно.

Рішення: Якщо виводить nouveau, nvidia або amdgpu, виправте прив’язку перед запуском VM.

Завдання 5: підтвердити, що модулі VFIO завантажені

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          69632  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   57344  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             425984  0
kvm                  1376256  1 kvm_intel

Значення: Якщо VFIO відсутній, passthrough буде ненадійним або зовсім не працюватиме.

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

Завдання 6: перевірити ізоляцію IOMMU груп для GPU

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$(basename "$(dirname "$d")") $(basename "$d")"; done | sort -n | egrep '01:00'
12 0000:01:00.0
12 0000:01:00.1

Значення: Ідеально, коли GPU і його аудіо-функція в одній групі самі по собі (або з пристроями, які ви теж передаєте).

Рішення: Якщо група містить чіпсетні пристрої або NVMe, який потрібен на хості — ймовірно, потрібне інше розміщення слотів або ACS override.

Завдання 7: перевірити конфігурацію VM у Proxmox на правильну машину/прошивку

cr0x@server:~$ qm config 120
agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 8
cpu: host,hidden=1,flags=+pcid
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-120-disk-0,discard=on,iothread=1
hostpci0: 0000:01:00.0,pcie=1,x-vga=1
hostpci1: 0000:01:00.1,pcie=1

Значення: bios: ovmf і machine: q35 зазвичай правильні. x-vga=1 може допомогти, якщо ви хочете GPU як первинний.

Рішення: Якщо у вас i440fx/SeaBIOS з сучасним GPU — перемкніть на Q35/OVMF, якщо немає доказів протилежного.

Завдання 8: прочитати журнал QEMU на предмет помилок при призначенні пристрою

cr0x@server:~$ journalctl -u pve-qm@120 --no-pager -n 120
... qemu-system-x86_64: vfio-pci 0000:01:00.0: BAR 1: can't reserve [mem 0x...] ...
... qemu-system-x86_64: vfio-pci 0000:01:00.0: failed to setup container for group 12: Failed to set iommu for container: Operation not permitted
... VM 120 start failed: QEMU exited with code 1

Значення: Проблеми з резервуванням BAR, помилки груп та проблеми з правами з’являються тут першими.

Рішення: Якщо QEMU не стартує — не женіться за драйверами гостя. Виправте хост/прошивку.

Завдання 9: перевірити, чи хост не захопив консоль (конфлікти фреймбуфера)

cr0x@server:~$ dmesg | egrep -i 'fbcon|efifb|simplefb|vesafb|nouveau|amdgpu' | head -n 60
[    1.234567] efifb: framebuffer at 0xe1000000, using 3072k, total 3072k
[    1.234890] fbcon: Deferring console take-over

Значення: Якщо хост прив’язав фреймбуфер до GPU, прив’язка VFIO може змагатися або не встигнути.

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

Завдання 10: підтвердити, що VM бачить GPU всередині (для Windows без агента)

cr0x@server:~$ qm monitor 120
(qemu) info pci
  Bus  0, device  1, function 0:
    VGA controller: PCI device 10de:1e87
      BAR0: 64 bit memory at 0x00000000f6000000 [0x01000000]
      BAR1: 64 bit memory at 0x00000000e0000000 [0x10000000]

Значення: QEMU перераховує пристрій і відображає BARи. Це не доводить роботу драйверів, але підтверджує базове перерахування.

Рішення: Якщо відсутній — повертайтесь до конфігурації VM (hostpci рядки, pcie=1) і перевірок IOMMU груп.

Завдання 11: виявити проблеми, пов’язані зі скиданням (GPU завис після вимкнення)

cr0x@server:~$ dmesg | egrep -i 'vfio-pci|reset|FLR|D3' | tail -n 60
[  912.345678] vfio-pci 0000:01:00.0: not ready 1023ms after bus reset; waiting
[  913.369012] vfio-pci 0000:01:00.0: not ready 2047ms after bus reset; giving up

Значення: GPU не скинувся чисто. Це часто дає чорний екран при наступному старті VM.

Рішення: Застосуйте обхідне рішення для скидання (vendor-reset для деяких AMD GPU, повний перезавантаження хоста або оберіть GPU, відомий тим, що скидається коректно).

Завдання 12: перевірити перенаправлення переривань та попередження ядра

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:|x2apic|ATS|posted interrupt' | head -n 80
[    0.123456] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.123789] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.

Значення: IRQ remapping зменшує «таємничі зависання пристроїв під навантаженням» і покращує ізоляцію.

Рішення: Якщо бачите попередження про відключене перенаправлення переривань — очікуйте нестабільності. Виправте BIOS/прошивку або розгляньте відповідні параметри ядра.

Завдання 13: підтвердити ситуацію з ROM GPU (лише при потребі)

cr0x@server:~$ echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/rom >/dev/null
cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/rom | head -c 16 | hexdump
0000000 55 aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000010

Значення: Заголовок ROM починається з 55 aa. Деяким GPU потрібен дамп ROM для ініціалізації у VM, особливо якщо він не первинний.

Рішення: Якщо читання ROM заблоковане або дає сміття — розгляньте надання відомого доброго ROM-файлу у конфігу VM (і робіть це лише за потреби).

Завдання 14: перевірити, чи hugepages / бекінг пам’яті не порушили DMA

cr0x@server:~$ grep -H . /proc/meminfo | egrep 'HugePages|Hugepagesize' 
/proc/meminfo:HugePages_Total:       8192
/proc/meminfo:HugePages_Free:        8000
/proc/meminfo:Hugepagesize:          2048 kB

Значення: Hugepages — це нормально, але неправильне розміщення або нестача пам’яті у хоста може спричиняти дивні відмови, що виглядають як проблеми GPU.

Рішення: Якщо хост під тиском пам’яті або hugepages фрагментовані — відкатіть «налаштування для продуктивності», поки VM не стане стабільною.

10 причин і виправлень (чорний екран)

1) Хост усе ще використовує GPU (неправильна прив’язка драйвера)

Класичний випадок. Ви передали GPU, але хост завантажив nvidia, amdgpu або nouveau першим.
VM стартує, але GPU напіввласний і поводиться так, ніби його тягнуть у дві сторони. Чорний екран — типовий результат.

Виправлення: прив’яжіть пристрій до vfio-pci рано (initramfs) та внесіть конфліктні модулі до blacklist.

cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb

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

Рішення: Після перезавантаження перевірте знову lspci -nnk. Якщо не показано vfio-pci, роботи не завершено.

2) IOMMU групи «брудні» (не вдається ізолювати GPU)

Якщо GPU знаходиться в IOMMU групі з іншими пристроями (USB-контролери, SATA, іноді цілий сусідній слот PCIe),
VFIO не може безпечно призначити лише GPU. Ви можете отримувати «працює один раз, потім чорний екран» або «працює до завантаження драйвера».

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

cr0x@server:~$ pvesh get /nodes/$(hostname)/hardware/pci --pci-class-blacklist ""
... 

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

3) Неправильна прошивка/тип машини (OVMF/Q35 mismatch)

SeaBIOS плюс i440fx ще може працювати, але це варіант «воно запускалося на моєму ноуті у 2017». Сучасні GPU і інсталятори ОС найщасливіші з OVMF + Q35.

Виправлення: встановіть bios: ovmf і machine: q35. Також додайте EFI-диск, якщо потрібно (Proxmox робить це в UI).

Рішення: Якщо ви прив’язані до SeaBIOS з якоїсь старої причини, можливо, доведеться надати ROM-файл і погодитись, що деякі GPU не співпрацюватимуть.

4) Ви дивитеся не на той відеовихід (порт і переговори з монітором)

Це принизливо, але реальне. Різні порти можуть поводитися по-різному під passthrough: DP link training,
HDMI EDID-особливості та режими економії енергії монітора можуть виглядати як «GPU помер».

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

Рішення: Якщо VM доступна по RDP/SSH, але локальний вивід чорний — ймовірно GPU справний; проблема в шляху виводу.

5) Пропущена аудіо-функція GPU (мультіфункціональний passthrough)

Багато GPU мають HDMI/DP аудіо-функцію. Деякі драйвери передбачають її наявність. Деякі скидання працюють краще, коли всі функції передані.
Передати лише VGA-функцію — і драйвер може завантажитися… а на екрані нічого не буде.

Виправлення: передавайте обидві 01:00.0 і 01:00.1 як окремі записи hostpci.

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

6) NVIDIA Code 43 / виявлення гіпервізора (менш поширено, але реальне)

В деяких середовищах Windows + драйвери NVIDIA вирішують, що їм не подобається віртуалізоване оточення і відмовляються правильно ініціалізувати GPU.
Симптоми різні: чорний екран, помилка пристрою, драйвери, які встановлюються, але ніколи не дають виводу.

Виправлення: використовуйте cpu: host,hidden=1 у конфігурації VM і уникайте екзотичного маскування прапорів CPU, якщо це не потрібно для ліцензування чи сумісності.

Рішення: Якщо ви виконуєте VDI-процеси — тестуйте версії драйверів. Це не суєта; відбуваються регресії.

7) Баг скидання (GPU не ініціалізується після перезапуску/вимкнення VM)

Деякі GPU не скидаються повністю без повного відключення живлення. Ви зупиняєте VM, запускаєте знову — і отримуєте чорний екран.
Перший запуск працює, що змушує звинувачувати гостя. Насправді GPU тримає образу.

Опції виправлення:

• Спробуйте повний перезавантаження хоста як діагностику. Якщо це «вирішує» проблему — ймовірно, це баг скидання.
• Для деяких карт AMD існує helper-модуль для відновлення роботи (залежить від платформи).
• Віддавайте перевагу GPU, відомим тим, що скидаються коректно для продакшену. «Працює, якщо ніколи не перезавантажувати» — це не стратегія.

Жарт #2: Якщо ваш GPU працює тільки після перезавантаження хоста — вітаю, ви побудували дуже дорогу вимикач-світло.

8) Розмір BAR / Above 4G decoding / Resizable BAR особливості

Сучасні GPU маплять великі регіони пам’яті (BAR). Якщо прошивка не може чисто виділити місце, ви побачите помилки резервування BAR,
випадкові падіння QEMU або VM, що завантажується, але ніколи не показує вивід, коли драйвер намагається відобразити VRAM.

Виправлення:

• Увімкніть «Above 4G decoding» в BIOS для великих BAR-виділень (часто обов’язково).
• Тимчасово відключіть Resizable BAR під час налагодження (особливо при змішаних старих гостях або прошивках).
• Залишайтеся на Q35 та OVMF для прогнозованої поведінки PCIe.

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

9) Плутанина з первинним GPU: x-vga, vBIOS та «немає емульованого дисплея»

Якщо ви прибрали емульований VGA-пристрій і очікуєте, що переданий GPU стане первинним, прошивка гостя має використовувати його як дисплей під час завантаження.
Іноді цього не відбувається, особливо якщо GPU не надає сумісний option ROM у спосіб, якого очікує VM.

Виправлення:

• Спробуйте x-vga=1 на пристрої passthrough GPU.
• Тимчасово збережіть базовий емульований дисплей для інсталяції/налагодження, потім видаліть його, коли ситуація стабільна.
• Якщо потрібно — надайте ROM-файл, що відповідає вашій моделі GPU.

Рішення: Якщо ви бачите екрани завантаження через емульований VGA, але втрачаєте вивід при переході на GPU — ви в території прошивки/option-ROM.

10) Управління живленням і стани сну (D3cold, ASPM та інші)

Деякі платформи агресивно переводять пристрої в низькопотужні стани. На bare metal драйвери справляються з цим.
При passthrough переходи живлення менш пробачливі. Драйвер гостя завантажується, змінює стан живлення GPU,
і ваш екран стає чорним.

Виправлення: відключіть PCIe ASPM в BIOS для тестування і уникайте suspend/hibernate всередині гостя, поки не доведете стабільність.

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

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

• Симптом: VM стартує, консоль Proxmox порожня, монітор чорний, але VM відповідає на пінг.
  Корінна причина: Вивід на іншому порту GPU або гість використовує інший адаптер виводу.
  Виправлення: Підключіться по RDP/SSH, встановіть переданий GPU як первинний дисплей, протестуйте інший фізичний порт, зменшіть частоту оновлення/відключіть HDR.
• Симптом: VM не стартує; QEMU виходить з помилками груп/контейнера.
  Корінна причина: IOMMU група не ізольована або IOMMU вимкнено/неправильно налаштовано.
  Виправлення: увімкніть VT-d/AMD-Vi, виправте параметри ядра, перемістіть слоти GPU, і тільки після цього розглядайте ACS override.
• Симптом: Працює один раз після перезавантаження хоста, потім чорний екран після перезапуску VM.
  Корінна причина: Баг скидання GPU / FLR не підтримується.
  Виправлення: уникайте частих stop/start, використайте vendor reset обхід або оберіть GPU з коректним скиданням.
• Симптом: Windows бачить GPU, але драйвер падає; чорний екран при завантаженні драйвера.
  Корінна причина: Невідповідність драйвера/гіпервізора, відсутня аудіо-функція або невідповідний режим прошивки.
  Виправлення: передайте всі функції, використайте OVMF+Q35, встановіть cpu: host,hidden=1, тестуйте стабільну гілку драйверів.
• Симптом: Хост втрачає відео після прив’язки GPU до VFIO; ви не бачите консолі.
  Корінна причина: Ви передали єдиний GPU, яким користується хост.
  Виправлення: використайте iGPU або дешеву додаткову GPU для консолі хоста, або працюйте headless через IPMI/serial та прийміть компроміс.
• Симптом: Випадкові зависання під навантаженням; інколи закінчується чорним екраном.
  Корінна причина: Перенаправлення переривань вимкнене, багатий BIOS або переходи управління живленням.
  Виправлення: оновіть BIOS, увімкніть IRQ remapping, відключіть ASPM для тестування, тримайте ядро в актуальному стані.
• Симптом: У логах QEMU згадується помилка резервування BAR.
  Корінна причина: Взаємодія Above 4G decoding/Resizable BAR або вичерпання адресного простору.
  Виправлення: увімкніть Above 4G decoding, тимчасово відключіть Resizable BAR, дотримуйтеся Q35/OVMF.

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

Інцидент №1: Аутейдж через хибне припущення

Команда хотіла «дешеве GPU-прискорення» для Windows CAD-навантаження. Вони зібрали Proxmox-ноду з однією великою GPU і припустили:
«VM використовує GPU, хост він не потрібен.» Вони навіть відключили емульований VGA, бо так було «чистіше».

VM стартувала нормально — один раз. Після технічного перезавантаження вона повернулася з чорним екраном. On-call пробував стандартне:
перевстановити драйвери, змінити кабелі, переключити OVMF-настройки. Безуспішно. VM була доступна в мережі, але локальний вивід не повернувся.

Приховане припущення полягало в тому, що GPU завжди покаже придатний boot-дисплей в OVMF. Насправді option ROM карти
не був консистентним у тій конфігурації. Без емульованого дисплея нічого не було видно під час раннього завантаження і ініціалізація драйвера мовчки падала.

Виправлення було нудним: додали емульований дисплей для інсталяції й налагодження, залишили Q35+OVMF, передали обидві функції GPU,
і видалили емульований адаптер тільки після підтвердження стабільності через кілька перезавантажень. Також додали дешеву вторинну GPU для консолі хоста.
«Дешеве прискорення» стало дешевшим з точки зору людогодин негайно.

Інцидент №2: Оптимізація, що відбилася боком

Інша організація ганялася за затримкою і вирішила «налаштувати все»: hugepages, pinning CPU, агресивне енергозбереження, увімкнене ASPM,
і кастомний cmdline ядра, скопійований з форумної гілки, що виглядала авторитетно.

VM з passthrough GPU завантажувалася, показувала вивід, а потім темніла під навантаженням — зазвичай при старті рендерджобу.
Їхній перший інстинкт був — драйвери. Вони закріпили більше ядер. Змінили профілі живлення Windows. Навіть поміняли монітори.
Чорний екран повертався як непрохане продовження.

Зрештою вони подивилися dmesg і виявили, що перенаправлення переривань фактично не працювало через налаштування BIOS, які взаємодіяли з режимом x2APIC.
Система була стабільна для легкого використання, але нестабільна під важким DMA/переривальним навантаженням.
«Оптимізація» перетворила майже робоче оточення на хитке.

Виправлення — відкат до відомої-робочої бази: стандартні параметри ядра Proxmox для IOMMU, оновлення BIOS,
відключення ASPM під час валідації і лише потім поетапне повернення налаштувань з планом відкату.
Продуктивність покращилась, бо система перестала падати. Це недооцінена оптимізація.

Інцидент №3: Нудна, але правильна практика, що врятувала день

Третя команда виконувала GPU passthrough для внутрішнього CI, що потребував сборок CUDA. Не гламурно, але близько до продакшену.
У них було правило: кожна зміна інфраструктури мала передзміну snapshot конфігу VM і дамп стану хоста.
Вони також вели текстовий лог PCI ID GPU, IOMMU груп і точної версії ядра Proxmox.

Одного ранку після рутинного оновлення ядра VMs почали завантажуватись у чорний екран. Почався панічний запуск — цю пайплайн годували релізи.
Але команда мала чеки: вони порівняли qm config до і після, підтвердили, що PCI ID не змінились,
і відразу побачили, що після оновлення initramfs GPU переприв’язався до хост-драйвера.

Оскільки в них був чекліст, вони не сперечалися про теорії. Перегенерували initramfs, підтвердили VFIO binding, перезавантажились один раз
і відновили роботу швидко. Без героїв. Без «перевстановлення гостя». Просто дисциплінована перевірка.

Практика не була сексуальною, але скоротила інцидент. В операціях найшвидший фікс часто — «докажіть, що змінилось», а потім акуратно відкотіть.

Чеклісти / покроковий план

Чекліст A: Готовність хоста (зробити до налаштування VM)

1. Увімкніть VT-d/AMD-Vi і (якщо доступно) перенаправлення переривань в BIOS.
2. Увімкніть Above 4G decoding для сучасних GPU; тимчасово відключіть Resizable BAR під час налагодження.
3. Завантажте хост і підтвердіть, що IOMMU увімкненний у dmesg.
4. Підтвердіть PCI ID GPU та ізоляцію IOMMU груп.
5. Прив’яжіть GPU + аудіо-функцію до vfio-pci в initramfs; занотуйте нативні драйвери в blacklist.
6. Перезавантажте і перевірте lspci -nnk на предмет прив’язки до vfio-pci.

Чекліст B: Конфігурація Proxmox VM (стабільні налаштування)

1. Використовуйте тип машини Q35 і BIOS OVMF для більшості сучасних GPU.
2. Додайте EFI-диск (UEFI vars) для OVMF.
3. Передайте GPU і його аудіо-функцію з pcie=1.
4. Почніть з емульованого дисплея під час інсталяції/налагодження; видаліть пізніше, якщо потрібно.
5. Встановіть тип CPU на host; для NVIDIA/Windows розгляньте hidden=1.
6. Запустіть один раз, встановіть драйвери, перезавантажте кілька разів, щоб перевірити поведінку при скиданні.

Чекліст C: План дій при чорному екрані (коли це трапляється о 2:00)

1. Підтвердіть, що VM жива в мережі (ping, RDP/SSH). Якщо відповідає — підозрюйте вивід/драйвери, а не завантаження VM.
2. Перегляньте journalctl -u pve-qm@VMID на предмет VFIO/BAR/групових помилок.
3. Перевірте прив’язку GPU на хості та повідомлення dmesg про скидання.
4. Якщо це баг скидання — зробіть контрольоване перезавантаження хоста, щоб відновити GPU, і сплануйте реальне вирішення (не «ніколи не перезавантажувати»).
5. Задокументуйте, що змінилось від останнього відомого робочого стану: оновлення ядра, налаштування BIOS, оновлення драйверів, зміни апаратної конфігурації VM.

FAQ

1) Чому VM завантажується нормально, але екран стає чорним при встановленні драйверів GPU?

Це часто перехід від базового VGA/UEFI framebuffer до повноцінного mode-setting драйвера. Підозрюйте невідповідність прошивки/типу машини,
відсутню аудіо-функцію, управління живленням або особливість драйвера/гіпервізора (включаючи Code 43 в деяких конфігураціях).

2) Що обрати: OVMF чи SeaBIOS для GPU passthrough?

Використовуйте OVMF для більшості сучасних GPU і нових гостьових ОС. SeaBIOS — для специфічних legacy-випадків або для налагодження,
але він обмежує можливості з сучасним обладнанням.

3) Q35 чи i440fx?

Q35, якщо немає вагомої причини інакше. GPU — це PCIe-пристрої; Q35 краще моделює PCIe і уникає багатьох дивностей.

4) Чи справді потрібно передавати аудіо-функцію GPU?

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

5) У мене тільки один GPU на хості. Чи можу я передати його і все ще керувати Proxmox?

Так, але очікуйте керування headless (SSH, web UI) і погоджуйтесь, що локальна консоль може зникнути.
Якщо цінуєте нерви — використайте iGPU, IPMI або дешеву додаткову GPU для хоста.

6) Який найшвидший спосіб зрозуміти, хостова чи гостьова проблема?

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

7) Чи викликає «iommu=pt» чорні екрани?

Зазвичай ні; це поширене налаштування для продуктивності. Але якщо платформа вже має хитку поведінку IOMMU, будь-яке тонке налаштування може це показати.
Під час налагодження спростіть: залиште обов’язкові прапори IOMMU, приберіть непотрібні оптимізації.

8) Як зрозуміти, що у мене баг скидання?

Шаблон: перший запуск VM працює, наступні запуски після вимкнення VM дають чорний екран, а dmesg показує таймаути VFIO reset.
Повний перезавантаження хоста «вирішує» проблему тимчасово. Це характерний симптом.

9) Чи безпечний ACS override?

Це обхід, який віддає гарантії ізоляції заради зручності. Для лабораторій часто прийнятно.
Для продакшену краще обирати апаратне забезпечення, що дає чисті IOMMU групи без хитрощів.

10) Чому консоль Proxmox порожня, хоча GPU передано?

Консоль Proxmox призначена для емульованого дисплея. Якщо ви покладаєтесь на переданий GPU для виводу, консоль може бути за задумом порожньою.
Тримайте емульований адаптер під час налагодження, щоб мати «очі» всередині VM.

Висновок: практичні наступні кроки

Ставтеся до чорного екрану як до проблеми маршрутизації, а не настрою. Починайте з хоста: IOMMU увімкнено, чиста IOMMU група, прив’язка vfio-pci.
Потім перевіряйте прошивку VM і модель машини (OVMF + Q35 — раціональна базова конфігурація). Лише потім підходьте до драйверів гостя і особливостей монітора.

Наступні кроки, що дають негайний ефект:

• Зробіть «знімок відомо-робочого» стану: /proc/cmdline, lspci -nnk, IOMMU групи і qm config.
• Підтверджуйте VFIO-binding після кожного оновлення ядра (update-initramfs може повернути прив’язку до хост-драйверів).
• Перевіряйте скидання, роблячи кілька циклів вимкнення/включення VM перед тим, як вважати систему готовою.
• Якщо зіткнулись із багом скидання — припиніть переговори з цією GPU і змініть план: обхідний модуль, інша модель або прийміть необхідність перезавантажень хоста.