PCIe passthrough у Proxmox проти ESXi: GPU, HBA, NIC — що простіше і що швидше

Коротке підсумування: що обрати

Якщо вам потрібна «максимальна передбачуваність для середнього домашнього лабу та багатьох малих компаній»

Proxmox зазвичай простіше для розуміння, бо це Linux від краю до краю. Ви бачите кожну ручку: IOMMU-групи, прив’язку драйверів, маршрутизацію переривань, особливості скидання. Коли щось ламається — це відбувається голосно, і ви можете дослідити хост як звичайний Linux-сервер.

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

Якщо вам потрібні «корпоративні обмеження та передбачуваний життєвий цикл»

ESXi — це чистіша корпоративна історія: списки сумісності пристроїв, стабільна площина управління та операційні шаблони, що масштабуються з командами. Для passthrough ESXi відмінний, коли ваші апарати на «щасливому шляху», і ваші вимоги відповідають очікуванням VMware.

Коли ви виходите за межі «щасливого шляху» — споживчі GPU, дивні скидання, нішеві NIC — ESXi стає ввічливим шерифом: він не буде з вами боротися, але просто не пустить.

GPU

• Простота: Proxmox зазвичай перемагає для DIY GPU passthrough. ESXi хороша, якщо ви в межах підтримуваних GPU / режимів (і ліцензії якщо потрібен vGPU).
• Швидкість: майже нативна на обох при правильному конфігуруванні. Обмеження частіше в CPU-розкладанні, топології PCIe або драйверах/енергоменеджменті, а не в гіпервізорі.

HBA (SAS/SATA контролери)

• Простота: Proxmox виграє, якщо ваша мета — «дати VM весь HBA і нехай вона запускає ZFS/TrueNAS». ESXi теж підходить, але ви витратите більше часу на сумісність і перевірки «чи дозволено це».
• Швидкість: passthrough фактично нативний, але реальна продуктивність залежить від глибини черг, модерації переривань і поведінки прошивки/драйвера.

NIC (10/25/40/100G, SR-IOV, DPDK-подібні навантаження)

• Простота: нічия, залежно від мети. ESXi має зрілі робочі процеси для SR-IOV; Proxmox має інструменти Linux і менше продуктових обмежень.
• Швидкість: SR-IOV або повний passthrough можуть бути відмінними на обох. Для загальної мережі часто паравіртуальні NIC (vmxnet3/virtio-net) — “достатньо швидкі” і простіші в експлуатації.

Суха і кумедна істина: passthrough дає нативну продуктивність разом з нативними проблемами.

Цікаві факти та коротка історія (корисно, не для вікторин)

1. Intel VT-d та AMD-Vi (IOMMU) — те, що робить можливим серйозну ізоляцію DMA. До цього «passthrough» був рулеткою з точки зору безпеки і стабільності.
2. VFIO (Virtual Function I/O) став основним підходом у Linux, бо чисто відокремлює доступ до пристрою від користувацького простору (QEMU) і покладається на IOMMU для безпеки.
3. Перенаправлення переривань (interrupt remapping) — велика річ для коректності та безпеки. Без нього деякі платформи не можуть безпечно віртуалізувати MSI/MSI-X у масштабі.
4. SR-IOV створили, щоб уникнути повного присвоєння пристрою, розділивши NIC на «віртуальні функції» з апаратно забезпеченою ізоляцією.
5. Баги зі скиданням GPU — не міф. Деякі GPU не реалізують належний function-level reset (FLR), тому «працює після вимкнення живлення» — реальний тип інциденту.
6. ACS (Access Control Services) впливає на IOMMU-групування. Споживчі плати часто групують кілька слотів разом, змушуючи вас передавати більше пристроїв або використовувати ACS override з компромісами.
7. NVMe був розроблений для глибоких черг та малої затримки. Погано віртуалізований NVMe «працює», аж поки ви не поставите на нього базу даних і не побачите дивні p99.
8. VMware DirectPath I/O існує багато років і зрілий, але свідомо консервативний: надає пріоритет підтримуваності та передбачуваності більше, ніж «дозвольте мені хакнути».
9. vMotion і passthrough завжди мали незручні стосунки. Ви не можете жити-мігрувати VM, яка володіє фізичним пристроєм, якщо не використовуєте спеціальні технології поділу/посредництва.

Як passthrough працює насправді (і де ламається)

PCIe-пристрої роблять дві важливі речі: вони відкривають конфігураційний простір (реєстри, можливості) і виконують DMA в оперативну пам’ять системи. Passthrough означає, що гостьова ОС отримує прямий доступ до пристрою, і гіпервізор здебільшого відходить убік — але має все одно берегти хост.

Три стовпи: IOMMU, ізоляція та скидання

• IOMMU зіставляє DMA пристрою з пам’яттю гостя. Без нього пристрій, присвоєний VM, може DMA-записати в ядро хоста і «переписати реальність».
• Ізоляція залежить від IOMMU-груп. Якщо два пристрої в одній групі, часто неможливо безпечно присвоїти лише один (вони можуть DMA-увати в адресний простір один одного або мати загальні трансляційні особливості).
• Поведіка при скиданні важлива. Коли VM перезавантажується, пристрій має повернутися у чистий стан. Якщо пристрій не може скинутися (або платформа не може його скинути), виникають проблеми «працює один раз».

Шлях Proxmox: VFIO + QEMU + Linux-драйвери

У Proxmox зазвичай роблять так:

1. Увімкнути IOMMU у прошивці та в kernel cmdline.
2. Прив’язати цільовий PCIe-пристрій до vfio-pci (а не до звичного драйвера хоста).
3. Додати рядки hostpci у конфіг VM, опціонально контролюючи ROM BAR, MSI та інші особливості.
4. Дозволити драйверу гостя володіти пристроєм.

Перевага: ви бачите все і можете змінювати. Недолік: ви бачите все і можете змінювати — тепер ви команда інтеграції.

Шлях ESXi: DirectPath I/O у рамках правил vSphere

В ESXi ви:

1. Увімкнете IOMMU в прошивці.
2. Позначите пристрій для passthrough у конфігурації хоста.
3. Перезавантажите хост (часто потрібно для перев’язки пристрою).
4. Додите пристрій до VM, прийнявши обмеження, наприклад відсутність vMotion.

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

Де це ламається у житті

• Погане групування IOMMU (поширено на споживчих платах): ви не можете ізолювати GPU від його аудіофункції або від USB-контролера за тим же upstream-містком.
• Помилки скидання: пристрій не повертається після зупинки VM; хост бачить пристрій, але драйвер гостя зависає; тільки перезавантаження хоста це виправляє.
• Шторм переривань або стрибки затримки: ви передали пристрій з високим IOPS, і тепер CPU0 плаче, бо переривання прив’язані ковдрою.
• Невідповідність прошивки/драйвера: BIOS хоста старий; прошивка HBA стара; драйвер гостя очікує іншого — виникає «привид» зберігання.

Цитата, бо підходить для життя опсів: Сподівання — не стратегія. — James R. Schlesinger

Жарт №1: Якщо ваш GPU скидається тільки після перезавантаження хоста, вітаємо — ви винайшли «високу доступність через терпіння».

Що простіше: Proxmox проти ESXi за типом пристрою

GPU passthrough

Proxmox простіше, коли ви поза корпоративними GPU-лійнами. Ви можете передати майже будь-який PCIe-GPU, якщо можете його ізолювати, прив’язати до VFIO та впоратися з проблемами скидання. Спільнотна мудрість існує, бо проблеми часті й відтворювані.

ESXi простіше, коли ваш GPU підтримується і ваш робочий процес відповідає очікуванням VMware. Якщо потрібен vGPU (розшарювання часу, кілька VM на GPU), екосистема ESXi історично сильніша, але тут починають грати роль ліцензування та участь вендора.

Практична реальність: найважче рідко буває «натиснути passthrough». Найважче — отримати стабільну поведінку через перезавантаження, оновлення драйверів і події живлення. Proxmox дає більше важелів. ESXi дає менше, але безпечніші важелі.

HBA passthrough (SAS HBA, RAID-карти в IT-режимі)

Якщо ви робите storage engineering, ви вже знаєте правило: прошивка RAID бреше. Якщо ви хочете ZFS або будь-який стек зберігання, що очікує прямого бачення дисків, вам потрібен HBA в IT-режимі або справжній HBA, і VM має ним володіти.

Proxmox робить це природним: прив’язати HBA до VFIO, передати його, дати TrueNAS/OmniOS/Linux бачити диски, керувати SMART і робити своє. Ви все ще можете тримати завантаження та пристрої управління на хості.

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

NIC passthrough: повний пристрій проти SR-IOV проти паравіртуального

Для більшості навантажень вам не потрібен повний NIC passthrough. virtio-net (Proxmox) і vmxnet3 (ESXi) відмінні. Вони також зберігають можливості міграції і роблять експлуатацію спокійнішою.

Коли це потрібно — NFV, наднизька затримка, великі пакети або VM як фаєрвол/роутер на 25/100G — ви вибираєте між:

• Повний passthrough: концептуально простіше, але вбиває мобільність і ускладнює мережу хоста.
• SR-IOV VFs: найкращий компроміс для багатьох проектів; ви зберігаєте частину контролю хосту і можете мапити кілька VM на один фізичний порт.
• DPDK/Userspace стеки: часто поєднуються з passthrough або SR-IOV; продуктивність хороша, але ви отримуєте проблему тонкого налаштування.

Переможець за простотою залежить від вашої команди: Linux-орієнтовані команди знайдуть Proxmox SR-IOV та налаштування IRQ простими; команди, що працюють у VMware, оцінять workflows ESXi і їхню послідовність у виробництві.

Що швидше: реальна продуктивність по навантаженнях

GPU продуктивність: зазвичай майже нативна, поки не стане нею

Коли GPU передано правильно, ви близькі до «голого» заліза за пропускною здатністю. Втрати продуктивності зазвичай викликані:

• Плануванням CPU: ваші vCPU не закріплені, хост перевантажено або латентні потоки перескакують між ядрами.
• NUMA-невідповідностями: GPU на одному сокеті, пам’ять VM на іншому. Штрафи по пропускній здатності і затримці можуть бути відчутні.
• Енергоменеджментом: агресивні ASPM або C-states можуть робити затримки нестабільними (залежить від платформи).

Proxmox дає прямий доступ до Linux-інструментів для NUMA pinning та hugepages; ESXi теж має зрілі контролі CPU/пам’яті, але «чому повільніше» іноді менш прозоре.

HBA passthrough: гіпервізор рідко є пляшковим горлом

Для HBA passthrough — це в основному «підключити пристрій до гостя». Проблеми продуктивності майже завжди пов’язані з:

• Неправильним режимом прошивки (IR/RAID замість IT/HBA).
• Невідповідністю глибини черги та модерації переривань.
• Поведінкою дисків (SMR-диски, енергоменеджмент, таймери відновлення після помилок).

Обидва гіпервізори можуть дати майже нативну продуктивність. Різниця в операційному плані: Proxmox легше корелювати логи хоста, PCIe-помилки та повідомлення ядра. ESXi зберігає консистентність середовища, але може ховати деталі низького рівня за своїми абстракціями.

NIC продуктивність: паравіртуальне недооцінене

На 10G virtio-net і vmxnet3 зазвичай чудові. На 25/100G починаєш хвилюватися про:

• Offloads (TSO/GSO/GRO/LRO) і чи вигідні вони вашому навантаженню.
• Розподіл переривань і черги RSS.
• Навантаження vSwitch проти прямих апаратних черг.

Повний passthrough і SR-IOV можуть зменшити накладні витрати, але вони зменшують можливість жити-міграції та централізованої політики. Якщо ваша мета — «швидко», passthrough може виграти. Якщо ваша мета — «швидко і розумно», паравіртуальне часто перемагає.

Жарт №2: Найшвидший NIC — це той, який ви не дебажите о 3 ранку.

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

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

1) Підтвердити, що IOMMU увімкнено (Proxmox/Linux хост)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU|AMD-Vi" | head
[    0.812345] DMAR: IOMMU enabled
[    0.812901] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.813210] DMAR: Interrupt remapping enabled

Значення: IOMMU і перенаправлення переривань активні. Це базова умова для безпечного passthrough.

Рішення: Якщо цього немає, зупиніться. Виправте налаштування BIOS (VT-d/AMD-Vi) і kernel cmdline перед зміною конфігів VM.

2) Перевірити, що kernel cmdline містить прапори IOMMU (Proxmox)

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 вмикає VT-d; iommu=pt використовує passthrough-режим для зменшення накладних витрат на хості.

Рішення: Якщо відсутні — оновіть GRUB і перезавантажте. Не «пробуйте як є». Ви втратите години.

3) Знайти пристрій, який хочете передати (PCI ID)

cr0x@server:~$ lspci -nn | egrep -i "vga|3d|ethernet|sas|raid|nvme"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 02)

Значення: У вас три класичні кандидати для passthrough: GPU (плюс його аудіо-функція), HBA та 10GbE NIC.

Рішення: Зверніть увагу на BDF-адреси (01:00.0, 03:00.0, 05:00.0). Ви будете використовувати їх у конфігах VM або при прив’язці драйверів.

4) Перевірити IOMMU-групи (чи можна ізолювати пристрій?)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename $g):"; ls -1 $g/devices/; done | sed -n '1,20p'
Group 0:
0000:00:00.0
Group 1:
0000:00:01.0
0000:01:00.0
0000:01:00.1
Group 2:
0000:00:03.0
0000:03:00.0
Group 3:
0000:05:00.0

Значення: Функції GPU 01:00.0 та 01:00.1 разом (добре), HBA ізольовано, NIC ізольовано. Це бажаний стан.

Рішення: Якщо GPU ділить групу з випадковими пристроями, або перемістіть слоти, змініть налаштування BIOS «PCIe ACS», або прийміть ACS override (з компромісами по безпеці).

5) Підтвердити, який драйвер зараз володіє пристроєм (перед прив’язкою до VFIO)

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: mpt3sas
	Kernel modules: mpt3sas

Значення: Хост наразі використовує драйвер HBA. Якщо ви передасте його, хост має його відпустити.

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

6) Прив’язати пристрій до vfio-pci (Proxmox/Linux)

cr0x@server:~$ echo "options vfio-pci ids=1000:0087,10de:2204,10de:1aef" | sudo tee /etc/modprobe.d/vfio.conf
options vfio-pci ids=1000:0087,10de:2204,10de:1aef

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

Значення: Ви сказали хосту прив’язувати ці PCI ID до VFIO при завантаженні.

Рішення: Перезавантажте хост у вікні технічного обслуговування. Гаряча перев’язка можлива, але в продакшні люди віддають перевагу нудній відтворюваності.

7) Перевірити, що vfio-pci тепер у використанні

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: vfio-pci
	Kernel modules: mpt3sas

Значення: Драйвер хоста відключено; VFIO володіє пристроєм. Це стан, який вам потрібен для passthrough.

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

8) Додати passthrough до конфігурації Proxmox VM (hostpci)

cr0x@server:~$ sudo qm set 120 --hostpci0 01:00,pcie=1 --hostpci1 03:00,pcie=1
update VM 120: -hostpci0 01:00,pcie=1 -hostpci1 03:00,pcie=1

Значення: VM 120 отримає GPU (обидві функції, якщо вказати 01:00) і HBA.

Рішення: Якщо потрібен GPU-audio і Proxmox не підхоплює його автоматично, передайте обидві функції явно. Потім завантажте VM і перевірте виявлення у гості.

9) Перевірити, що QEMU стартує з приєднаними пристроями (Proxmox)

cr0x@server:~$ sudo journalctl -u pvedaemon -n 20 | tail
Dec 28 10:12:41 server pvedaemon[2123]:  starting task UPID:server:00003A1B:0002C2F9:676FFB29:qmstart:120:root@pam:
Dec 28 10:12:43 server pvedaemon[2123]: VM 120 started with pid 14592

Значення: VM стартувала. Це не доводить, що пристрій ініціалізувався, але виключає негайну відмову QEMU.

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

10) У гості підтвердити видимість GPU/HBA (Linux guest)

cr0x@server:~$ lspci -nn | egrep -i "vga|sas|scsi"
00:10.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
00:11.0 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
00:12.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)

Значення: VM бачить реальний апарат. Тепер битва за драйвери та стабільність, а не за підключення.

Рішення: Якщо відсутній — ймовірно ви передали неправильний BDF, пристрій досі прив’язаний до драйвера хоста або неправильний тип машини/налаштування PCIe у VM.

11) Перевірити помилки PCIe/AER на хості (стабільність лінку)

cr0x@server:~$ dmesg | egrep -i "aer|pcie bus error|vfio|DMAR" | tail -n 8
[  912.344120] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
[  912.344141] pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[  912.344148] pcieport 0000:00:01.0: AER:   device [8086:1901] error status/mask=00000001/00002000
[  912.344152] pcieport 0000:00:01.0: AER:    [ 0] RxErr

Значення: Кореговані помилки трапляються, але часті спалахи корелюють з зависанням GPU, падіннями NIC або дивними NVMe поведінками. Причини — цілісність сигналу, riser-кабелі, живлення або BIOS.

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

12) Перевірити розподіл переривань (хост) для passthrough NIC/HBA

cr0x@server:~$ cat /proc/interrupts | egrep -i "vfio|ixgbe|i40e|mpt3sas" | head
  55:   182934   0   0   0  IR-PCI-MSI  524288-edge      vfio-pci
  56:   176211   0   0   0  IR-PCI-MSI  524289-edge      vfio-pci

Значення: Переривання потрапляють лише на CPU0 (перший стовпець). Це може бути нормальним при низьких швидкостях, але класична причина стрибків затримки.

Рішення: Якщо важливий p99, налаштуйте баланс переривань/пінінг так, щоб переривання розподілялися по ядрах відповідно до NUMA-локальності.

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

cr0x@server:~$ iostat -x 1 3
Linux 6.6.15 (vm-storage) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda            120.0   250.0    6.0    18.0      96.0     3.20    8.50     4.10    10.60   0.70  25.2

Значення: await — середня затримка запиту в мс. Якщо ви очікували NVMe-поведінку і бачите 8–15ms, щось вищестояще не так (пристрій, диски, черги, режим контролера).

Рішення: Якщо затримка висока — перевірте, чи HBA в IT-режимі, перевірте диски та інспектуйте PCIe-помилки хоста. Не звинувачуйте гіпервізор першим.

14) ESXi: перевірити, чи пристрій придатний для passthrough (концептуальна паритетна задача)

cr0x@server:~$ esxcli hardware pci list | egrep -n "0000:03:00.0|Passthru" -A2
214:0000:03:00.0
215:   Class Name: Serial Attached SCSI controller
216:   Passthru Capable: true

Значення: ESXi розпізнає пристрій і каже, що його можна передати.

Рішення: Якщо Passthru Capable — false, зупиніться і перевірте підтримку платформи/BIOS/IOMMU і чи ESXi має драйвер/quirk-підтримку для цього пристрою.

Швидкий план діагностики: знайти пляшкове горло без здогадів

Це послідовність «увійти в кімнату криз і бути корисним за 10 хвилин». Вона впорядкована. Не пропускайте кроки, бо нудно.

Перше: підтвердити підключення та ізоляцію

1. Чи увімкнено IOMMU? (dmesg/cmdline або налаштування хоста ESXi). Якщо ні — далі не має значення нічого.
2. Чи пристрій ізольований у своїй IOMMU-групі? Якщо ні — очікуйте нестабільності або відмови старту.
3. Чи пристрій прив’язаний до правильного драйвера? Proxmox: vfio-pci. ESXi: позначено для passthrough і вимагає перезавантаження.

Друге: перевірити поведінку скидання і життєвий цикл

1. Холодний запуск хоста → запуск VM → зупинка VM → запуск VM знову. Повторити один раз.
2. Якщо на другому запуску не працює — підозрюйте FLR/скидання. Це дуже поширено для GPU.
3. Перевірте логи хоста на помилки VFIO reset або проблеми з повторною навчанням PCIe link.

Третє: перевірити нудні апаратні реалії

1. PCIe-помилки (AER) у dmesg або логах ESXi. Кореговані помилки у спалахах — запах проблеми.
2. Терміка і живлення: GPU + HBA + NIC в одному шасі можуть створити свято перехідних явищ живлення.
3. Вирівнювання прошивок: BIOS, VBIOS GPU, прошивка HBA. Стара прошивка викликає нові болі.

Четверте: виміряти у гості під правильним кутом

1. GPU: перевіряйте частоти і завантаження, а не лише FPS. Якщо частоти тротлінгу — це не гіпервізор.
2. Зберігання: дивіться на затримки (iostat -x) і глибини черг, а не лише на пропускну здатність.
3. Мережа: дивіться на падіння пакетів, CPU переривань і розподіл RSS, а не лише на iperf-цифри.

П’яте: тільки потім тонко налаштовуйте

1. NUMA pinning та hugepages для стабільної затримки.
2. Баланс переривань/пінінг для стабільності NIC/HBA під навантаженням.
3. Вимкнути агресивні енергосхеми, якщо джиттер затримок вас вбиває.

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

1) VM не стартує після додавання hostpci

Симптом: завдання Proxmox падає; QEMU скаржиться на VFIO або «group not viable».

Причина: пристрій ділить IOMMU-групу з іншим використовуваним пристроєм, або IOMMU не увімкнено.

Виправлення: Увімкніть VT-d/AMD-Vi, перевірте dmesg; перемістіть карту в інший слот; уникайте ACS override, якщо не готові до компромісів ізоляції.

2) GPU працює один раз, потім чорний екран при перезавантаженні VM

Симптом: перший запуск ок; після вимкнення/перезапуску драйвер гостя зависає або пристрій зникає.

Причина: GPU не має надійної підтримки FLR/скидання; хост не може чисто скинути функцію.

Виправлення: Спробуйте іншу модель GPU; використайте vendor-reset де доступно; віддавайте перевагу серверним/робочим GPU для доступності; плануйте перезавантаження хоста як спосіб відновлення (і документуйте це).

3) Продуктивність зберігання «нормальна» до навантаження бази, потім p99 вибухає

Симптом: бенчмарки виглядають ок; реальне навантаження має стрибки затримки та таймаути.

Причина: HBA у RAID/IR режимі замість IT/HBA, невідповідність черг, або переривання прикріплені до одного ядра; іноді SMR-диски ведуть себе по-своєму.

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

4) NIC passthrough VM має велику пропускну спроможність, але випадкові втрати пакетів

Симптом: iperf показує лінійну швидкість; реальний трафік має втрати і ретрансляції.

Причина: дисбаланс переривань, неправильна RSS-налаштування, занадто малі кільця, або PCIe-помилки під навантаженням.

Виправлення: Перевірте переривання, налаштуйте драйвер у гості, перевірте стабільність лінку (AER), і вирівняйте NUMA (NIC поруч із CPU/пам’яттю, що використовується).

5) ESXi відмовляється робити passthrough пристрій, хоча апарат підтримує це

Симптом: ESXi відмовляє пристрій для DirectPath I/O.

Причина: IOMMU в BIOS відключено, баг у прошивці платформи, або пристрій/драйвер не на тому підтримуваному шляху, який очікує ESXi.

Виправлення: Увімкніть IOMMU в BIOS, оновіть BIOS, перевірте підтримку пристрою і розгляньте SR-IOV/паравіртуальне замість passthrough, якщо пристрій «сніжинка».

6) Ви передали HBA… і тепер зникло сховище хоста

Симптом: хост іноді завантажується; після змін завантажувальний диск відсутній або ZFS pool не знайдено.

Причина: ви передали контролер, на якому знаходяться ваші boot або дані. Класичне самосаботування.

Виправлення: Відокремте boot-storage хоста від passthrough-зберігання. Ставте це як жорстку вимогу дизайну, а не пропозицію.

Три корпоративні міні-історії (анонімізовано, правдоподібно, болісно знайомо)

Інцидент через неправильне припущення: «IOMMU-групи прив’язані до слотів, так?»

Команда успадкувала невеликий кластер віртуалізації, що зростав органічно: кілька високоядерних серверів, змішані NIC і один «спеціальний» GPU вузол для ML-експериментів. План був простий: додати другий GPU в вільний слот, передати обидва у різні VM і дати групі дата-сайанс self-service.

Вони уважно налаштували Proxmox — VFIO binding, hostpci записи, задокументували, яка VM за яку карту відповідає. Перший GPU працював. Другий теж… але тільки коли перша VM була вимкнена. Коли обидві були увімкнені, одна VM зависала під навантаженням, а в іншої сипалися PCIe помилки.

Неправильне припущення було тонким: вони вважали, що материнська плата ізолює кожний слот у свою IOMMU-групу. Насправді два слоти ділили upstream PCIe міст без ACS separation, і платформа групувала кілька пристроїв разом. «Порожній слот» не був операційно незалежним — лише фізично порожнім.

Виправлення не вимагало хитрих параметрів ядра. Вони перемістили один GPU в слот на іншому root-complex, оновили BIOS і прийняли, що топологія плати — це параметр дизайну, а не післядумка. Post-incident note був коротким і гострим: «PCIe топологія — це вхідний параметр дизайну, а не думка на потім».

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

Фінтех-подібна команда мала чутливі до затримки сервіси і звичку тонкої налаштування. Вони перемістили мережевий appliance VM в Proxmox і дали SR-IOV VFs, щоб досягти пакетних швидкостей, які не вдавалося отримати з чистим virtio-net. Це спрацювало. Тож вони зробили стандартні ритуали продуктивності: відключили C-states CPU, встановили governor в performance і підкрутили coalescing NIC, щоб зменшити накладні витрати.

На папері пропускна здатність виросла. Використання CPU впало. Всі плескали один одному. Потім хвостова затримка у клієнтів почала погіршуватись періодично, і лише під певними патернами трафіку. Занадто довго шукали кореляцію: важкі сплески створювали мікро-сплески в appliance VM, а нові налаштування coalescing перетворили «багато маленьких своєчасних переривань» у «кілька великих грудок переривань».

Гірше, відключення C-states змінило теплову поведінку. Вентилятори реагували дивно, і один хост почав логувати кориговані PCIe-помилки під тривалим навантаженням. Нічого не впало, але система жила ближче до краю. «Оптимізація» витратила кілька малих буферів безпеки й витратила їх усі.

Відкат був нудним: повернути coalescing до дефолту, зберегти розумні енергопараметри і тільки пінити CPU та налаштовувати IRQ там, де метрика це виправдовувала. Вони залишили SR-IOV, бо воно вирішувало основну проблему, але припинили намагатися перехитрити апарат без чіткого p99-ціля. Урок: тюнінг продуктивності без моделі латентності — це культ з кращою термінологією.

Нудна, але правильна практика, що врятувала ситуацію: «Ми провели тест перезавантаження»

Медіа-компанія запускала GPU-акселерацію для транскоду на ESXi. У них було вікно для оновлень: прошивка хостів, оновлення ESXi і драйверів гостя. Середовище було стабільним, тож спокуса була зробити оновлення і вважати справу зробленою.

Натомість їхній опс-лід наполіг на «тесті життєвого циклу перезавантажень» для одного хоста: оновити, потім циклувати кожну VM через start/stop/start двічі і зробити повний перезавантаження хоста між проходами. Здавалося зайвим і займало час.

На другому перезапуску VM після патча один GPU не ініціалізувався. Це не відбувалось послідовно. Це не показалося в базових smoke-тестах. Але це було реальним, і режим відмови саме такий, що перетворюється на інцидент о 2 ранку при випадковому перезавантаженні хоста.

Оскільки вони встигли спіймати це в staging, змогли відкотити комбінацію драйверів і запланувати підтримуване вендором оновлення прошивки пізніше. Жодної драми. Жодного впливу на клієнтів. Проста календарна зустріч і виправлений runbook. Нудна практика — тестувати життєвий цикл, а не тільки перший запуск — була різницею між «невеликою затримкою» і «великою аварією».

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

Чекліст дизайну (перед тим, як торкатися конфігів)

• Визначте незмінне: чи потрібна жива міграція, HA restart, snapshots, або це «pet VM», прив’язана до хоста?
• Виберіть стратегію для пристроїв: повний passthrough vs SR-IOV vs паравіртуальне. За замовчуванням — паравіртуальне, якщо не можете назвати пляшкове горло.
• Підтвердіть топологію: до якого CPU socket прив’язаний слот? Яка IOMMU-група? Не гадайте.
• Відокремте boot від passthrough-пристроїв: хост має завантажуватися і бути керованим без переданого контролера.
• Документуйте відновлення після скидання: що робити, коли пристрій не ініціалізується? Перезавантаження хоста? Вимкнення живлення? Скриптоване від’єднання/повторне приєднання?

Proxmox покроково (практичний базовий рівень)

1. Увімкніть VT-d/AMD-Vi в BIOS/UEFI. Увімкніть «Above 4G decoding», якщо робите GPU/NVMe з великими BAR.
2. Додайте kernel params (intel_iommu=on або amd_iommu=on, плюс iommu=pt), перезавантажте.
3. Перевірте IOMMU-групи; при потребі перемістіть карти.
4. Прив’яжіть пристрої до vfio-pci через /etc/modprobe.d/vfio.conf, оновіть initramfs, перезавантажте.
5. Додайте hostpci записи до VM; використовуйте pcie=1 для сучасних пристроїв.
6. Завантажте гість, встановіть драйвери вендора, перевірте стабільність через кілька циклів start/stop.
7. Лише потім: NUMA pinning, hugepages, налаштування IRQ якщо у вас є вимоги по виміряній латентності.

ESXi покроково (операційно безпечний базовий рівень)

1. Увімкніть IOMMU в BIOS/UEFI.
2. Підтвердіть, що пристрій бачиться і «passthru capable».
3. Позначте пристрій для passthrough у конфігурації хоста; перезавантажте хост.
4. Додайте пристрій до VM; пам’ятайте, що vMotion зазвичай недоступний.
5. Перевірте драйвери гостя і поведінку життєвого циклу (start/stop/reboot цикли).
6. Якщо потрібна мобільність, оцініть SR-IOV (для NIC) або mediated/vGPU (для GPU) в межах ваших підтримуваних обмежень.

Операційний чекліст (те, що треба внести в runbook)

• Як підтвердити, що пристрій приєднано (команди хоста і гостя).
• Як відновитись після помилки скидання (точні кроки, вимоги до вікна технічного обслуговування).
• Як безпечно патчити (порядок: прошивка, гіпервізор, драйвери гостя; валідаційні цикли).
• Які логи збирати для ескалації (dmesg/AER хоста, VM логи, логи драйверів гостя).
• Які функції відключено (міграція, snapshots, suspend/resume), щоб ніхто не здивувався пізніше.

Питання та відповіді (FAQ)

1) Чи швидший PCIe passthrough за virtio/vmxnet3?

Іноді. Для високих пакетних швидкостей, низької латентності або специфічних offload-ів passthrough/SR-IOV може виграти. Для загальних навантажень паравіртуальні пристрої часто в межах досяжності і набагато простіші в експлуатації.

2) Чому мій GPU passthrough працює при першому запуску, але падає після перезавантаження VM?

Через поведінку скидання. Деякі GPU не реалізують надійний FLR, або платформа не може чисто скинути пристрій. В кінці ви отримуєте потребу в перезавантаженні хоста або вимкненні живлення для відновлення.

3) Чи варто передавати HBA у TrueNAS/ZFS VM?

Якщо хочете, щоб VM повністю володіла дисками з повним баченням (SMART, обробка помилок), так — HBA passthrough це поширений, розумний дизайн. Просто переконайтесь, що хост не залежить від цього HBA для завантаження чи управління.

4) Чи безпечний ACS override у Proxmox?

Він може змусити речі «працювати», розбивши IOMMU-групи, але це не магічна ізоляція. Ви змінюєте гарантії безпеки заради гнучкості. В продакшні краще мати апарат, що дає чисті групи без override.

5) Чи можу я жити-мігрувати VM з passthrough?

Загалом — ні. Повний passthrough прив’язує VM до фізичного хоста. Деякі медійовані підходи (SR-IOV, vGPU) відновлюють часткову мобільність, але вони мають платформені обмеження.

6) Яка найбільша пастка продуктивності з passthrough?

NUMA і переривання. Переданий NIC/HBA/GPU може бути «швидким», але давати жахливу хвостову латентність, якщо переривання і локальність пам’яті неправильно налаштовані.

7) Чи потрібні hugepages для GPU passthrough?

Не обов’язково. Hugepages можуть зменшити тиск на TLB і покращити стабільність для деяких навантажень, але вони додають обмеження на алокацію. Використовуйте їх, коли маєте вимірювану користь або відомі шаблони навантаження.

8) Для NIC краще SR-IOV чи повний passthrough?

Часто SR-IOV. Воно дає майже passthrough-продуктивність і дозволяє хосту зберігати контроль над PF. Але додає операційної складності (життєвий цикл VF, сумісність драйверів, політика безпеки).

9) Чому ESXi каже, що мій пристрій не придатний для passthrough?

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

10) Який загалом простіший для змішаного GPU + HBA + NIC passthrough хоста?

Proxmox простіший, якщо хочете експериментувати і дебажити на рівні Linux. ESXi простіший, якщо хочете обмеження і ваша апаратура мейнстрім і підтримується.

Висновок: наступні кроки, які реально допоможуть

Якщо ви обираєте платформу для PCIe passthrough, не починайте з ідеології. Почніть з бюджету на відмови та потреб у міграції.

• Якщо вам потрібна мобільність та операції на флоті, за замовчуванням обирайте паравіртуальні пристрої, і використовуйте passthrough лише там, де це вимірно виправдано. Тут ESXi часто сильніший.
• Якщо вам потрібен максимальний контроль над пристроєм і ви готові жити в логах ядра та топології PCIe, Proxmox — гарний вибір — особливо для експериментів з GPU та HBA passthrough.
• Яку б платформу ви не обрали, ставтесь до passthrough як до проєкту інтеграції апаратного забезпечення: перевіряйте IOMMU-групування, поведінку скидання і стабільність життєвого циклу до того, як щось пообіцяєте стейкхолдерам.

Практичний наступний крок: виберіть одне цільове навантаження, збудуйте один хост і програйте цикл тесту життєвого циклу (start/stop/reboot двічі) перед масштабуванням. Ця нудна вправа попередить більшість дорогих сюрпризів.