Немає IOMMU в Proxmox? Виправте за 10 хвилин (UEFI + параметри ядра)

February 7, 2026 • February 7, 2026 • Читання: 7 хв • Views: 0

Було корисно?

Ви намагаєтесь зробити те, у чому Proxmox відомий: passthrough PCIe. GPU, HBA, NIC — будь‑що. І тут хост спокійно повідомляє: No IOMMU detected. Переклад: ваш гіпервізор у пов’язках на очах, а ви просите його жонглювати пилососами.

Зазвичай це не «помилка Proxmox». Це невідповідність між режимом прошивки (UEFI/Legacy), апаратними можливостями віртуалізації CPU (VT‑d / AMD‑Vi) та параметрами ядра, які фактично вмикають IOMMU. Виправити це швидко, якщо знаєте, куди дивитись — і неймовірно дратівливо, якщо ні.

Що насправді означає «No IOMMU detected»

У віртуалізації x86 IOMMU — це апаратний блок, який дозволяє хосту контролювати DMA (прямий доступ до пам’яті) від пристроїв. Без нього PCIe‑пристрій може потенційно читати/писати пам’ять, до якої не повинен мати доступ. Це неприйнятно для безпечного passthrough.

Proxmox (KVM/QEMU під капотом) потребує, щоб ядро відкрило активний IOMMU. Якщо ви бачите «No IOMMU detected», то одне з наступного правдиве:

CPU/чипсет не підтримує його (рідко на сучасних серверах; частіше на бюджетних десктопних компонентах).
Прошивка вимкнула функцію (VT‑d для Intel, AMD‑Vi/IOMMU для AMD).
Ви завантажили систему в режимі/конфігурації, де ядро його не включає (відсутні параметри ядра, неправильна конфігурація завантажувача, нюанси Secure Boot).
IOMMU ввімкнено, але ви дивитесь не на ті докази (поширено — grep по неправильному журналу, і ви женетеся за примарами).

І важлива експлуатаційна правда: «IOMMU увімкнено» на практиці не є бінарним станом. Ви можете мати виявлений IOMMU з жахливою груповою ізоляцією, непрацюючою ремаппінгом переривань або пристроєм, що не скидається. Усі вони перешкоджатимуть стабільному passthrough.

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

Якщо ви поспішаєте (а ви поспішаєте), виконайте ці кроки в порядку. Це не філософія — це швидкість.

Перший: доведіть, чи бачить ядро IOMMU

Перевірте живі повідомлення ядра на наявність Intel DMAR або AMD‑Vi. Це найшвидше джерело істини.

cr0x@server:~$ dmesg | egrep -i 'dmar|iommu|amd-vi|ivrs' | head -n 50
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0

Що це означає: Якщо ви бачите «DMAR: IOMMU enabled» (Intel) або «AMD‑Vi: IOMMU enabled» (AMD), то повідомлення «No IOMMU detected» походить із іншого рівня або з попереднього завантаження.

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

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

cr0x@server:~$ cat /sys/firmware/efi/fw_platform_size 2>/dev/null || echo "Not booted via UEFI"
64

Що це означає: «64» означає завантаження через UEFI. Якщо вивід — «Not booted via UEFI», ви в режимі legacy. Це може працювати, але UEFI на сучасних платформах зазвичай менш примхливий.

Висновок: Якщо платформа підтримує UEFI — використовуйте його. Змішування legacy‑завантаження з сучасними можливостями віртуалізації часто приносить проблеми у вихідні.

Третій: перевірте, чи параметри ядра реально застосовано

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

Що це означає: Ви маєте бачити intel_iommu=on для Intel або amd_iommu=on для AMD. Часто також бажано iommu=pt для зменшення накладних витрат на пристрої, які залишаються під керуванням хоста.

Висновок: Якщо прапори відсутні — виправляйте GRUB або systemd‑boot. Якщо вони є, а в dmesg все одно немає IOMMU — причиною є прошивка або апаратне обмеження.

Цікавинки (і трохи історії) про IOMMU

DMA існує задовго до сучасної віртуалізації. Ранні системи дозволяли пристроям писати безпосередньо в пам’ять, бо CPU були повільні, а копіювання буферів — дороге.
Intel VT‑d та AMD‑Vi з’явилися через потребу гіпервізорів у безпечному DMA. Без IOMMU passthrough фактично означає «довіряємо пристрою і молимось».
ACPI‑таблиця «DMAR» — ключовий артефакт. На Intel ядро часто виявляє можливість IOMMU через DMAR, який надає прошивка.
Ремаппінг переривань важливий. Робочий IOMMU — це не лише трансляція адрес; коректний ремаппінг переривань зменшує вектор атак і покращує ізоляцію.
IOMMU‑групи — це, здебільшого, історія материнської плати/топології. Групи залежать від PCIe‑root‑портів, свічів і поведінки ACS.
ACS не придумували для домашніх лабораторій. Це функція PCIe для забезпечення ізоляції в багатокористувацьких системах — але хобісти швидко помітили, що вона допомагає VFIO‑розбиттю.
«iommu=pt» — компроміс щодо продуктивності. Воно використовує mappings pass‑through для хост‑пристроїв (менше накладних витрат), зберігаючи ізоляцію для VFIO‑пристроїв.
UEFI не зробив усе простішим; він зробив інакшим. Багато платформ постачають кращі ACPI‑таблиці в режимі UEFI, але також додають нюанси Secure Boot та NVRAM.

Попередні перевірки: підтвердьте CPU, режим прошивки та завантажувач Proxmox

Перед тим як чіпати BIOS, визначте, з чим маєте справу. Це виробнича практика: спочатку виміряйте, потім змінюйте.

Завдання 1: визначте вендора CPU та можливості віртуалізації

cr0x@server:~$ lscpu | egrep 'Vendor ID|Model name|Virtualization|Flags'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) CPU E-2278G @ 3.40GHz
Virtualization:                  VT-x
Flags:                           ... vmx ... dmar ...

Що це означає: Для Intel вам потрібні VT‑x (віртуалізація CPU) і VT‑d (IOMMU). VT‑d не завжди явно видно в цьому виводі; зазвичай перевіряють платформу та логи DMAR. Для AMD буде svm для віртуалізації, а AMD‑Vi перевіряють у dmesg.

Висновок: Якщо CPU — низького класу або якийсь вбудований SKU, спочатку переконайтеся, що він взагалі підтримує IOMMU, перш ніж звинувачувати Proxmox.

Завдання 2: підтвердьте наявність модулів ядра, пов’язаних з IOMMU

cr0x@server:~$ lsmod | egrep 'vfio|iommu|kvm' | head
vfio_pci               16384  0
vfio_pci_core          69632  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 не доводять, що IOMMU увімкнено, але показують, що базова інфраструктура є.

Висновок: Якщо VFIO відсутній і ви плануєте passthrough — налаштуйте його пізніше. Для проблеми «No IOMMU detected» спочатку зосередьтесь на прошивці та параметрах cmdline.

Завдання 3: дізнайтеся, чи Proxmox використовує GRUB або systemd-boot

cr0x@server:~$ proxmox-boot-tool status 2>/dev/null || echo "proxmox-boot-tool not in use"
Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace
System currently booted with: uefi
Configured ESPs: /boot/efi

Що це означає: Якщо proxmox-boot-tool використовується, зазвичай це systemd‑boot з ESP (EFI System Partition). Якщо ні — можливо GRUB.

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

Завдання 4: підтвердьте записи завантажувача (шлях systemd-boot)

cr0x@server:~$ bootctl status 2>/dev/null | sed -n '1,120p'
System:
     Firmware: UEFI 2.70
  Secure Boot: disabled
   Setup Mode: user
Boot Loader:
     Product: systemd-boot 252
    Features: ✓ Boot counting
Default Boot Entry: proxmox

Що це означає: Ви використовуєте systemd‑boot. Proxmox зазвичай керує cmdline ядра через /etc/kernel/cmdline.

Висновок: Якщо у вас systemd‑boot, редагування /etc/default/grub може нічого не змінити. Це типовий витрачений час.

Завдання 5: підтвердьте, що GRUB встановлений/активний (шлях GRUB)

cr0x@server:~$ grub-probe /boot 2>/dev/null && echo "GRUB tooling present"
ext2
GRUB tooling present

Що це означає: Інструменти GRUB присутні, але це не доводить, що він активний. Порівняйте з перевірками UEFI вище.

Висновок: Якщо ви завантажені через UEFI і systemd‑boot активний, вважавайте GRUB відволіканням, якщо ви явно його не встановлювали.

Налаштування UEFI/BIOS, які важливі (і які — ні)

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

Платформи Intel (поширені назви)

Intel Virtualization Technology (VT‑x): Увімкнює віртуалізацію CPU. Потрібно для KVM, але цього замало для passthrough.
Intel VT‑d: Це і є IOMMU. Саме це вам потрібно.
Above 4G decoding: Корисно/необхідно при passthrough GPU або кількох пристроїв з великими BAR. На деяких платах це також міняє алокацію ресурсів PCIe, покращуючи групування.
Resizable BAR: Може ускладнювати passthrough у деяких конфігураціях. Під час налагодження тимчасово вимкніть.
SR‑IOV: Не обов’язково для IOMMU, але часто поруч. Увімкніть лише якщо потрібні VF.

Платформи AMD (поширені назви)

SVM: Віртуалізація CPU (KVM). Увімкніть.
IOMMU / AMD‑Vi: Сам IOMMU. Увімкніть.
ACS / ACS Enable: Іноді доступне, іноді ні. Не покладайтеся на його наявність.
Above 4G decoding: Та сама історія, що й для Intel; часто потрібне для стабільного passthrough GPU.

Налаштування прошивки, якими люди зазвичай переймаються (зазвичай даремно)

«UEFI vs Legacy» як магічний перемикач: UEFI може допомогти, але не замінює увімкнення VT‑d/AMD‑Vi.
C‑states: Керування живленням може спричиняти затримки, але не викликає «No IOMMU detected». Не чіпайте десяток налаштувань одночасно.
XMP/EXPO: Профілі пам’яті можуть дестабілізувати хости, але не вимикають IOMMU. Для production‑систем тримайте профілі консервативними.

Жарт №1: Якщо ваше BIOS‑UI виглядає як меню DVD‑плеєра 2009 року — не хвилюйтеся: налаштування IOMMU все одно там десь ховаються.

Параметри ядра: GRUB vs systemd-boot (10‑хвилинне виправлення)

Коли прошивка в порядку, ядро все одно має вмикати IOMMU. У Proxmox це звичайно одна рядкова зміна плюс оновлення завантажувача.

Виберіть прапори для вашого вендора

Intel: intel_iommu=on iommu=pt
AMD: amd_iommu=on iommu=pt

Навіщо iommu=pt? Це прагматичний дефолт для багатьох хостів: хост‑пристрої використовують passthrough‑відображення (менше накладних витрат), тоді як VFIO‑пристрої все одно отримують ізоляцію. Якщо ви робите сувору багатокористувацьку ізоляцію — можливо, інша політика краща. Більшість користувачів Proxmox цього не потребують.

Завдання 6 (systemd-boot): встановіть прапори у /etc/kernel/cmdline

cr0x@server:~$ sudo cat /etc/kernel/cmdline
root=ZFS=rpool/ROOT/pve-1 ro quiet

Що це означає: Це шаблон командного рядка ядра.

Висновок: Додайте відповідні прапори для вашого вендора CPU.

cr0x@server:~$ sudo nano /etc/kernel/cmdline

Відредагуйте, наприклад, так:

cr0x@server:~$ sudo cat /etc/kernel/cmdline
root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt

Тепер застосуйте:

cr0x@server:~$ sudo proxmox-boot-tool refresh
Running hook script 'proxmox-auto-removal'..
Running hook script 'zz-proxmox-boot'..
Refreshing ESP /boot/efi
Copying kernel and creating EFI boot entry

Що це означає: Записи в ESP оновлюються з новим cmdline.

Висновок: Якщо ви не бачите оновлення ESP — можливо, ви не використовуєте systemd‑boot або ESP не змонтований коректно.

Завдання 7 (GRUB): встановіть прапори у /etc/default/grub та update-grub

cr0x@server:~$ sudo grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

Що це означає: Тут додають прапори для типових GRUB‑налаштувань.

Висновок: Додайте прапори для вендора і зазвичай iommu=pt.

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet"/GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"/' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-3-pve
Found initrd image: /boot/initrd.img-6.8.12-3-pve
done

Що це означає: Конфігурація GRUB тепер містить потрібні прапори.

Висновок: Якщо update-grub не знаходить ваші образи ядра Proxmox — ви або не використовуєте GRUB, або у вас незвична структура /boot.

Завдання 8: перезавантаження та підтвердження cmdline

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.

Після перезавантаження:

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

Що це означає: Запущене ядро має потрібні прапори.

Висновок: Якщо прапорів немає — ви редагували не те місце для вашого завантажувача. Поверніться до завдань із визначення завантажувача.

Перевірка роботи IOMMU (і як інтерпретувати вивід)

IOMMU не «відчувається» — його доводиться доводити. Ось перевірки, яким я довіряю.

Завдання 9: ще раз перевірте dmesg на увімкнення IOMMU (після змін)

cr0x@server:~$ dmesg | egrep -i 'DMAR: IOMMU enabled|AMD-Vi: IOMMU enabled|IOMMU enabled' | head
[    0.000000] DMAR: IOMMU enabled

Що це означає: Ядро використовує IOMMU.

Висновок: Якщо нічого немає — прошивка все ще не вмикає VT‑d/AMD‑Vi або платформа не надає таблиці коректно.

Завдання 10: перевірте ремаппінг переривань / повідомлення DMAR

cr0x@server:~$ dmesg | egrep -i 'remapping|x2apic|DMAR:.*fault|AMD-Vi:.*Event' | head -n 50
[    0.000000] DMAR: Interrupt remapping enabled

Що це означає: Ремаппінг переривань увімкнено (добре). Якщо бачите повідомлення про DMAR‑faults — це може вказувати на багу прошивки або пристрій, що робить незаконний DMA.

Висновок: Повторювані помилки не ігноруйте. Вони сильно корелюють з «VM раптово зависає при I/O».

Завдання 11: перевірте наявність IOMMU у sysfs

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups 2>/dev/null | head
0
1
2
3

Що це означає: Якщо /sys/kernel/iommu_groups існує й має пронумеровані директорії — ядро створило IOMMU‑групи.

Висновок: Якщо директорії відсутні — активного IOMMU немає.

Завдання 12: перерахунок груп і пристроїв (щире тестування)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; for d in "$g"/devices/*; do echo -n "  "; lspci -nns "$(basename "$d")"; done; done | sed -n '1,60p'
Group 0
  00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
Group 1
  00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]
Group 7
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1b80] (rev a1)
  01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f0] (rev a1)

Що це означає: Пристрої в одній і тій же групі не можна безпечно роз’єднати для passthrough. GPU часто показує аудіофункцію в тій самій групі — це нормально. Але якщо GPU поділяє групу з SATA‑контролером, з якого ви завантажуєтесь, — це погано.

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

IOMMU‑групи: яким має бути «добре»

IOMMU‑групи — це різниця між «passthrough — це галочка» і «passthrough — це квартальний проєкт». Потрібна чиста ізоляція. Ідеалу рідко досягають. Погоджуєтесь на безпечне.

Чого ви хочете

Ваш пристрій для passthrough (GPU/HBA/NIC) ізольований у власній групі або ділиться лише зі своїми функціями (multi‑function devices).
Материнські контролери, від яких залежить завантаження хоста (SATA/NVMe з кореневим томом Proxmox), не перебувають у тій самій групі з пристроєм passthrough.
PCIe‑root‑порти й мости формують логічну ізоляцію між слотами.

Що можна терпіти

GPU + його аудіофункція в одній групі.
NIC з кількома функціями, згрупований разом (залежить від апаратури).

Чого не варто терпіти

HBA у тій самій групі з чипсетом SATA, на якому розташовані завантажувальні диски Proxmox.
GPU, що поділяє групу з USB‑контролером, який вам потрібен для клавіатури/консолі під час аварій (спитайте, як я знаю; краще не питати).

Жарт №2: IOMMU‑групи як розсадка в офісі — якщо Фінанси й Виробництво сидять за одним столом, скоро буде аудит.

Основи VFIO: чисто прив’язати пристрої

Коли IOMMU увімкнено і групи прийнятні, хост все одно має припинити захоплювати пристрій власним драйвером. VFIO хоче, щоб пристрій був присвоєний йому першим.

Завдання 13: визначте PCI‑ID пристрою, який будете передавати

cr0x@server:~$ lspci -nn | egrep -i 'vga|nvidia|amd|ethernet|sas|sata' | head -n 20
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1b80] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f0] (rev a1)

Що це означає: vendor:device ID у дужках. Тут: 10de:1b80 і 10de:10f0.

Висновок: Зазвичай ви прив’язуєте всі функції, які збираєтесь передати (GPU + аудіо). Не прив’язуйте половину multi‑function пристрою, якщо любите налагоджувати.

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3301
        Kernel driver in use: nouveau
        Kernel modules: nouveau

Що це означає: Хост використовує nouveau. Для passthrough зазвичай хочуть, щоб пристрій використовував vfio-pci.

Висновок: Плануйте прив’язати до vfio‑pci і занести у чорний список драйвери хоста, які автоматично підключаються.

Завдання 15: налаштуйте VFIO IDs

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1b80,10de:10f0 disable_vga=1
EOF

Що це означає: Це каже vfio‑pci захопити ці пристрої на ранньому етапі.

Висновок: Якщо це production‑хост і GPU використовується для консолі, перегляньте рішення. Passthrough означає, що хост не повинен залежати від цього пристрою.

Завдання 16: занесіть у чорний список конфліктні GPU‑драйвери (приклад для nouveau)

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
options nouveau modeset=0
EOF

Що це означає: Запобігає автоматичному підключенню вбудованого відкритого драйвера NVIDIA під час завантаження.

Висновок: Блокуйте лише те, що конфліктує. Не починайте блокувати все підряд — так можна випадково позбавити хост мережі.

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

cr0x@server:~$ sudo tee -a /etc/modules >/dev/null <<'EOF'
vfio
vfio_pci
vfio_iommu_type1
vfio_virqfd
EOF

Що це означає: Забезпечує завантаження модулів під час старту. Деякі конфігурації працюють без цього, але багато краще поводяться з раннім завантаженням VFIO.

Висновок: Якщо ви переслідуєте періодичні проблеми з прив’язкою — раннє завантаження VFIO часто допомагає.

Завдання 18: оновіть initramfs і перезавантажте

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

Що це означає: Ваш initramfs тепер містить оновлені конфіги модулів для раннього завантаження.

Висновок: Перезавантажтесь, щоб протестувати чисту прив’язку; не намагайтесь hot‑unbind GPU на системі, яку потрібно зберегти доступною.

Завдання 19: підтвердьте, що пристрій тепер прив’язано до vfio-pci

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3301
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau

Що це означає: «Kernel driver in use: vfio-pci» — це ознака перемоги. У полі «Kernel modules» все ще можуть бути вказані потенційні модулі — це нормально.

Висновок: Якщо пристрій досі у власності nouveau/nvidia/amdgpu — ваш blacklist або оновлення initramfs не спрацювали, або пристрій використовується як основна консоль.

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

Покроково: виправляємо «No IOMMU detected» у реальному житті

Підтвердьте режим завантаження: UEFI чи legacy через /sys/firmware/efi. Вирішіть, чи стандартизувати на UEFI.
Визначте завантажувач: systemd‑boot чи GRUB. Редагуйте відповідний файл конфігурації.
Увімкніть опції прошивки: VT‑d (Intel) або IOMMU/AMD‑Vi (AMD). Також увімкніть SVM/VT‑x для віртуалізації CPU.
Увімкніть Above 4G decoding: Особливо при passthrough GPU/HBA або кількох PCIe‑пристроях.
Додайте прапори ядра: intel_iommu=on iommu=pt або amd_iommu=on iommu=pt.
Оновіть записи завантаження: proxmox-boot-tool refresh для systemd‑boot або update-grub для GRUB.
Перезавантажтесь: Не довіряйте частковим станам.
Перевірте в dmesg: «IOMMU enabled», і бажано — ремаппінг переривань.
Перевірте групи: Переконайтесь, що цільовий пристрій у безпечній групі.
Прив’яжіть VFIO: Вкажіть ids для vfio‑pci, заблокуйте конфліктні драйвери, оновіть initramfs, перезавантажтесь.
Перевірте стабільність VM: Запустіть VM, навантажте, переконайтесь, що скидання та перезавантаження працюють послідовно.

Контроль безпеки перед передаванням контролерів зберігання

Переконайтесь, що HBA не в тій самій IOMMU‑групі, що й контролер завантаження.
Переконайтесь, що root Proxmox не знаходиться на дисках, підключених до контролера, який ви передаєте.
Майте доступ поза мережею (IPMI/iKVM) або план на випадок втрати зв’язку.
Створіть знімок конфігурації VM і зафіксуйте PCI‑адреси перед змінами.

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

Саме тут витрачається найбільше часу: не на виправлення, а на впевненість у виправленні не того.

1) Симптом: «No IOMMU detected» навіть після додавання intel_iommu=on

Причина: Ви редагували GRUB, але хост завантажується через systemd‑boot (або навпаки).
Виправлення: Підтвердіть через bootctl status і proxmox-boot-tool status. Додайте прапори в /etc/kernel/cmdline для systemd‑boot і виконайте proxmox-boot-tool refresh.

2) Симптом: dmesg показує IOMMU увімкненим, але GUI Proxmox все ще скаржиться

Причина: Ви дивитесь на застарілу інформацію (старе завантаження), або попередження від конфіг‑перевірки VM очікує VFIO‑модулі та групи, а не лише IOMMU.
Виправлення: Перезавантажтесь, потім перевірте cat /proc/cmdline і ls /sys/kernel/iommu_groups. Переконайтесь, що модулі VFIO завантажені і групи ізоляції прийнятні.

3) Симптом: VM стартує, але пристрій не видно всередині гостя

Причина: Драйвер хоста все ще володіє пристроєм або ви прив’язали лише частину multi‑function пристрою.
Виправлення: Використайте lspci -k щоб підтвердити vfio-pci. Прив’яжіть усі релевантні функції (GPU + аудіо). Оновіть initramfs і перезавантажтесь.

4) Симптом: «IOMMU‑групи непридатні» / величезні групи, що містять половину системи

Причина: Топологія материнської плати не має ACS‑ізоляції; часто на споживчих платах.
Виправлення: Спробуйте інші PCIe‑слоти, увімкніть Above 4G decoding, оновіть BIOS і лише потім розгляньте ACS override (розуміючи, що це знижує реальну ізоляцію).

5) Симптом: Passthrough працює один раз, потім перестає після перезавантаження VM

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

6) Симптом: Хост втрачає зв’язок після увімкнення VFIO / прив’язки NIC

Причина: Ви прив’язали management NIC (або всю її групу) до vfio‑pci, тим самим позбулися мережі хоста.
Виправлення: Відв’яжіть, видаливши ids/blacklist, побудуйте initramfs повторно, перезавантажтесь. Використовуйте доступ поза мережею. Наступного разу перед прив’язкою перевірте групи.

7) Симптом: «DMAR: DRHD: handling fault status» засмічує логи

Причина: Баги прошивки/IOMMU або пристрій виконує незаконний DMA.
Виправлення: Оновіть BIOS, підтвердьте правильні прапори ядра, спробуйте вимкнути агресивне енергозбереження PCIe у прошивці. Якщо проблема лишається — можливо, платформа ненадійна для passthrough.

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

Міні‑історія 1: Аварія через хибне припущення

Команда, з якою я працював, успадкувала кластер Proxmox, що «безумовно підтримував passthrough». Хтось одного разу зробив це на іншому вузлі, в іншій стійці, під час міграції. Це стало племінною істинністю. Наступним кроком було передати HBA VM зберігання — бо це здавалося найшвидшим шляхом імпортувати купу дисків.

Вони увімкнули VT‑d у BIOS, додали intel_iommu=on у GRUB, перезавантажились і вирішили, що все готово. Потім вони прив’язали HBA до vfio‑pci. Хост впав: циклічне завантаження, відсутній root device, типовий жахливий тиша після обриву SSH. На місці довелося підключати crash cart, бо поза мережею доступ не був налаштований. Довгий післяполудень.

Причина була не екзотичною. HBA, яке вони «передавали», насправді не було окремою платою. Це був вбудований контролер зберігання. Він жив у тій же IOMMU‑групі, що й функції чипсету, які містили кореневий том. Вони припустили, що «назва контролера схожа на HBA» означає «безпечний для passthrough». Ядро не погодилось.

Виправлення було буденним: зупинитись, замапити IOMMU‑групи і фізично встановити справжній виділений HBA в слот, який групувався чисто. Потім прив’язати лише цей пристрій. Урок не «будь обережним». Урок: ніколи не припускайте ідентичність за маркетинговою назвою. PCI‑адреси та IOMMU‑групи — єдина надійна номенклатура.

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

Інша інфраструктура хотіла максимум продуктивності для навантаження на GPU. Хтось прочитав, що трансляція IOMMU додає накладні витрати, і вирішив «оптимізувати» параметри ядра та прошивки до кращого бенчмарку. Конфігурація розійшлась: один вузол мав iommu=pt, інший — ні, третій мав інші PCIe‑налаштування, бо «йому треба було так для завантаження».

Деякий час все здавалося нормальним. Потім почалися рідкісні, важко відтворювані збої: VM з GPU зависали під сильним I/O, тоді як хост залишався здебільшого живим. Проблема не була тривіальною для відтворення, але достатньо частою, щоб виснажити інженерів. Вони шукали помилки в драйверах гостя, версіях QEMU, живленні. І це не жарт.

Виявилась причина: нестабільність конфігурації навколо IOMMU і ремаппінгу переривань у поєднанні з різними версіями BIOS. Один вузол після оновлення прошивки мав вимкнений ремаппінг переривань. Під певним навантаженням цей вузол «падав». Оптимізація сама по собі не була прямо причиною; причина була в відсутності стандартизації.

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

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

Менший підрозділ мав пару вузлів Proxmox для внутрішніх сервісів. Вони не були складними. Але у них була одна звичка, яку я поважаю: для кожного вузла вони тримали простий файл «hardware mapping» у репозиторії ops — PCI‑адреси, що за пристрій і що йому дозволено.

Коли вони вирішили передати NIC у VM‑фаєрвол, вони не почали з редагування modprobe‑файлів. Вони почали з перевірки мапи, потім перевірили IOMMU‑групи в житті, потім спланували зміну під вікно з тестованим поза мережею доступом. Також виконали це поетапно: прив’язати VFIO, перезавантажитись, підтвердити, що хост досі досяжний, і тільки потім додати пристрій у VM.

У день зміни NIC, який вони хотіли передати, був у тій же групі з вбудованим USB‑контролером. Передача зробила б віддалене відновлення складнішим, бо їх USB‑IP‑KVM був на тому контролері. Нічого не зламалося, бо вони не продовжили. Вони перемістили NIC в інший слот і групи покращились.

Нічого екстраординарного не сталося. Ось у чому справа. «Сумна» практика — тримати карту пристроїв і трактувати зміни як зміни — запобігла самостійній аварії. Надійність — це, здебільшого, мистецтво не дивуватися власній інфраструктурі.

Операційна цитата (парафразована ідея)

Парафразована ідея: «Сподівання — це не стратегія.» — часто цитують в операційних колах, пов’язують з прагматичним управлінням інженерними процесами (парафраз)

FAQ

1) Чи потрібен UEFI для використання IOMMU у Proxmox?

Ні, але UEFI зазвичай дає кращі таблиці прошивки і менше несподіванок на сучасному обладнанні. Якщо можете вибирати — обирайте UEFI і будьте послідовні на всіх вузлах.

2) В чому різниця між VT‑x і VT‑d?

VT‑x — це віртуалізація CPU (ефективне виконання VM). VT‑d — це IOMMU (безпечний DMA і passthrough PCI). Для VM потрібен VT‑x/SVM; для passthrough — VT‑d/AMD‑Vi.

3) Чи завжди слід використовувати `iommu=pt`?

Для більшості хостів Proxmox з passthrough — так: це хороший дефолт. Якщо ви прагнете максимальної ізоляції для всіх хост‑пристроїв, можете уникати його — але очікуйте додаткових накладних витрат.

4) Я увімкнув IOMMU, але групи великі. Чи безпечно використовувати ACS override?

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

5) Чому Proxmox все ще скаржиться після зміни BIOS‑опцій?

Бо опції BIOS не мають значення, якщо параметри ядра не застосовано, або ви змінили конфігурацію неправильного завантажувача. Перевіряйте /proc/cmdline і dmesg, а не надії.

6) Чи можна передати контролер завантаження NVMe?

Можна, але не слід, якщо Proxmox завантажується з нього. Якщо ви віддасте контролер VM — хост втратить доступ. Щоб мати NVMe напряму у VM, встановіть другий контролер або використайте виділений диск.

7) Чи змінює ZFS щось у IOMMU?

Безпосередньо — ні. ZFS впливає на патерни cmdline завантаження (наприклад, root=ZFS=...) і може впливати на керування завантажувачами (часто використовується systemd‑boot). IOMMU — це все ще поведінка прошивки + ядра.

8) Як дізнатися, чи пристрій безпечний для passthrough?

Перевірте його IOMMU‑групу. Якщо група містить лише цей пристрій (і його функції), то все гаразд. Якщо спільна з критичними хост‑пристроями — перемістіть у інший слот або перегляньте план.

9) Мій GPU прив’язано до vfio‑pci, але VM не стартує. Що далі?

Перевірте проблеми зі скиданням і переконайтесь, що ви передали всі функції (GPU + аудіо). Перевірте тип машини та прошивку VM (OVMF/UEFI для сучасних GPU). Далі дивіться логи QEMU — там зазвичай є явна помилка.

10) Чи може Secure Boot спричинити «No IOMMU detected»?

Secure Boot зазвичай впливає на завантаження модулів і підписані ядра більше, ніж на виявлення IOMMU. Але він може ускладнити шлях завантаження і змусити думати, що ви застосували прапори, коли ні. Перевіряйте /proc/cmdline.

Наступні кроки (що робити після того, як все запрацювало)

Якщо IOMMU увімкнено й групи прийнятні, не зупиняйтесь на «VM запустилася». Виконайте експлуатаційні перевірки, щоб запобігти майбутнім інцидентам:

Тести перезавантаження: Багаторазово перезавантажте VM. Перезавантажте хост один раз. Якщо пристрій працює лише після холодного старту — це проблема надійності перед вашим наступним вікном оновлення.
Чистота логів: Слідкуйте за dmesg на предмет DMAR/AMD‑Vi помилок під навантаженням. Flooding помилками — не норма.
Контроль змін: Збережіть версію BIOS, режим завантаження, cmdline ядра і ids vfio. Стандартизуйте по вузлах, якщо їх більше одного.
Обмежуйте сферу passthrough: Передавайте мінімально необхідний набір пристроїв. Не давайте VM весь світ, бо це було простіше, ніж подумати.

Якщо ви виконали все вищевказане і все ще бачите «No IOMMU detected», ви у одній з неприємних крайніх ситуацій: прошивка, що брешуть, платформа без реального VT‑d/AMD‑Vi, або шлях завантаження, про який ви не знали. Тоді припиніть змінювати і почніть доводити кожен шар: прошивка → cmdline → dmesg → групи. Системи не реагують на інтуїцію. Вони реагують на конфігурацію.