Ваші ВМ відчуваються «повільними», тому ви починаєте купувати процесори, ніби це релігійний обряд. Насправді ж справжній винуватець часто — відсутня IOMMU група, перемикач у BIOS, поганий governor або хост, який прив’язує переривання на той самий ядро, куди ви прив’язали свою «чутливу до затримок» ВМ. Ласкаво просимо у домашню віртуалізацію: місце, де слабке місце завжди те, про яке ви не подумали перевірити.
Це практичний, орієнтований на експлуатацію огляд функцій процесора, які дійсно мають значення для запуску KVM/Proxmox, ESXi, Hyper-V, bhyve або Xen вдома. Не маркетингові чеклісти. Не форумні забобони. Функції, режими відмов і як довести наявність потрібних можливостей за допомогою команд.
Що справді має значення (а що ні)
Якщо ви будуєте або оновлюєте домашній сервер для віртуалізації, вибір CPU — це насамперед про можливості, потім про послідовність, і вже в останню чергу про чисту швидкість. Більшість домашніх лабораторій не ламаються через відсутність 5% одноядерної продуктивності. Вони ламаються, коли «підтримувана» функція фактично недоступна або поводиться погано під навантаженням.
Функції CPU, які є базовими вимогами
- Апаратна віртуалізація: VT-x або AMD-V. Без неї сучасні гіпервізори або не запустяться, або працюватимуть як у 2006 році.
- Друге рівневе транслювання адрес: EPT або NPT. Це різниця між «ВМ відчуваються нативними» і «ВМ — як покарання».
- IOMMU: VT-d або AMD-Vi. Потрібно для серйозного passthrough (GPU, HBA, NIC) і корисне для ізоляції навіть без passthrough.
- Адекватна прошивка: BIOS/UEFI, що коректно відкриває функції і не має дивних значень за замовчуванням.
Функції CPU, що залежать від навантаження
- AES-NI / VAES: Якщо ви використовуєте шифроване сховище (ZFS native encryption, LUKS), VPN або багато TLS‑навантаження — різниця може бути колосальною.
- AVX2/AVX-512: Корисні для специфічних завдань (транскодування медіа, певні аналітичні задачі). Можуть знизити турбочастоти або збільшити споживання енергії — тут потрібні компроміси.
- TSX, RDT тощо: Іграшки для тонкого тюнінгу в ентерпрайзі. Іноді корисні, зазвичай не потрібні вдома.
Функції, якими люди занадто захоплюються
- «Більше ядер завжди краще»: Поки не наситите пропускну здатність памʼяті, L3 кеш або здатність хоста планувати переривання.
- «Просто пропустити GPU»: Чудово, коли працює. Жах підтримки, коли IOMMU групи «склеєні» конструкцією материнської плати.
- «Тільки ECC або нічого»: ECC — це хороша інженерна практика, але не єдиний фактор, що вбереже від хаосу. (Це також не функція CPU; це характеристика платформи.)
Жорстка правда: віртуалізація — це менше про «запустити багато ОС» і більше про «змусити памʼять і I/O чемно поводитися під конкуренцією». Функції CPU, що покращують віртуалізацію памʼяті та ізоляцію пристроїв, — це ті, що дійсно мають значення.
Цікаві факти та історичний контекст
Трохи контексту економить дорогоцінні помилки. Ось кілька конкретних пунктів, що пояснюють, чому існують ці функції і чому гіпервізору це важливо:
- Бінарна трансляція колись була реальністю. До того як VT-x/AMD-V стали зрілими, гіпервізори переписували привілейовані інструкції. Це працювало, але було складно й повільно в деяких навантаженнях.
- EPT/NPT змінили гру більше, ніж VT-x/AMD-V. Рання апаратна віртуалізація без хорошого другого рівня трансляції все ще мала великий оверхед через shadow page tables.
- IOMMU не створювали для геймерів. Воно зʼявилося з потреб ентерпрайзу: ізоляція DMA, безпечне призначення пристроїв і спосіб не дозволити одному пристрою писати в чужу памʼять.
- VM exits — це збирач податків. Кожного разу, коли ВМ мусить перейти в гіпервізор за привілейованою операцією, ви платите. Сучасні CPU додають можливості саме для зменшення таких exit-ів.
- Nested virtualization колись була жахливою. Запуск гіпервізора всередині ВМ (для CI, лабораторій або «бо можу») був болючим, поки CPU й гіпервізори не поліпшилися.
- Meltdown/Spectre змінили базові очікування щодо продуктивності. Міри захисту збільшили оверхед для деяких операцій ядра/гіпервізора; деякі покоління CPU постраждали більше.
- SR-IOV — це побратим passthrough. Замість передачі цілого NIC у ВМ, ви розбиваєте його на віртуальні функції. Чудово, коли підтримується; неактуально, коли NIC цього не вміє.
- Intel і AMD називають схожі речі по-різному. VT-x vs AMD-V, EPT vs NPT, VT-d vs AMD-Vi. Мета одна: зменшити роботу гіпервізора.
Розширення апаратної віртуалізації: обовʼязкові речі
Розберемося з базою.
VT-x / AMD-V: необхідно, але недостатньо
Апаратні розширення віртуалізації дозволяють CPU виконувати код гостьової ОС у спеціальному режимі і безпечно перехоплювати чутливі операції в гіпервізорі. Більшість сучасних CPU це мають. Підступ у тому, що «має VT-x» не означає «чудовий CPU для віртуалізації». Це як казати, що «є руль» означає «гоночний автомобіль».
На що слід звертати увагу:
- Стабільність під навантаженням: якість прошивки і зрілість мікрокоду мають значення.
- Повнота функцій: EPT/NPT, віртуалізація переривань, posted interrupts тощо.
- Підтримка у вашому гіпервізорі: наявність функції в кремні не гарантує, що ваша платформа її коректно використовує.
Жарт #1: Купувати CPU для віртуалізації лише тому, що в нього є «VT-x» — це як купувати машину лише тому, що в неї є «кермо». Технічно вірно. Практично марно.
Nested virtualization: якщо ви цього хочете — плануйте
Nested virtualization поширена в компаніях для CI, лабораторій і тестування автоматизації гіпервізора. Вдома це нішево, але якщо ви запускаєте Kubernetes у ВМ, яка запускає інші ВМ (ви знаєте, хто ви), вам потрібна підтримка nested у CPU та гіпервізорі, і бажано тестувати це заздалегідь.
IOMMU/VT-d/AMD-Vi: passthrough і ізоляція
Якщо ви хочете GPU passthrough, HBA passthrough або «моє VM-роутер має власний NIC», ви увійшли у територію IOMMU. Тут збірки вдома виграють або програють через особливості платформи, а не через модель CPU.
Що насправді робить IOMMU
IOMMU для DMA те саме, що MMU для доступу CPU до памʼяті. Він дозволяє системі контролювати, які адреси памʼяті пристрій може читати/записувати через DMA. Без нього передача пристрою у ВМ небезпечна, бо пристрій може DMA-записом потрапити в памʼять хоста. З IOMMU ви можете відображати адреси, видимі для пристрою, на памʼять гостя безпечно.
Проблема IOMMU груп
Passthrough — це не «можу ввімкнути VT-d». Це «чи пристрої, які мені потрібні, ізольовані в прийнятні IOMMU групи». Материнські плати інколи підключають кілька пристроїв за одним PCIe root complex без правильної ACS (Access Control Services) сегрегації. Результат: ваш GPU в одній групі з SATA-контролером, який потрібен для хоста. Насолоджуйтеся вибором.
Доставка переривань і затримки
Навіть з IOMMU продуктивність залежить від того, як обробляються переривання. Сучасні системи можуть робити interrupt remapping, а гіпервізори — використовувати posted interrupts, щоб зменшити VM exits. Це велика справа для високих швидкостей мережі та низьколатентного зберігання.
Операційна позиція: якщо passthrough — критична вимога, купуйте платформу, відому своєю поведінкою. Бренд CPU менш важливий, ніж поведінка материнської плати + чипсета.
EPT/NPT, TLB і чому віртуалізація памʼяті — справжня суть
Коли хтось каже «оверхед віртуалізації», зазвичай мається на увазі «щось із CPU». Правда в тому, що найбільший історичний біль був у трансляції памʼяті і тому, як вона спричиняє флуктуації в кешах і TLB.
Second-level address translation (SLAT)
Intel EPT і AMD NPT дозволяють CPU перекладати гостьові віртуальні адреси у гостьові фізичні, а потім у фізичні адреси хоста апаратно. Без цього гіпервізор підтримував shadow page tables, і кожне оновлення таблиці сторінок гостя перетворювалося на дорогі операції. SLAT знімає значний оверхед.
TLB, розміри сторінок і чому hugepages інколи допомагають
Translation Lookaside Buffers (TLB) кешують трансляції адрес. Віртуалізація додає ще один шар, тому тиск на TLB може зрости. Hugepages (2MB, 1GB) можуть зменшити пропуски TLB для памʼяттєво-інтенсивних ВМ, але також можуть посилити фрагментацію або ускладнити overcommit памʼяті. Це інструмент, а не догма.
Overcommit: яма для продуктивності
Домашні лабораторії люблять overcommit, бо RAM дорога, а оптимізм безкоштовний. Функції CPU не врятують, якщо хост починає свопити. Як тільки ви бачите swap-in/swap-out під навантаженням ВМ, ваша «проблема CPU» — насправді проблема ємності та поведінки памʼяті.
Ядра vs такти vs кеш: як обрати процесор
Вибір CPU — це не лише «наскільки швидкий». Це «як він поводиться, коли 12 завдань одночасно хочуть обслуговування». Гіпервізори підсилюють погані компроміси, бо вони мультиплексують усе.
Ядра: конкурентність і запас планування
Більше ядер означає більше потоку виконання, що може просуватися без очікування. Це добре для багатьох дрібних сервісів, CI і «я запускаю все в окремих ВМ, бо так чистіше». Але більше ядер також може означати:
- нижчі турбо-частоти всіх ядер при тривалому навантаженні
- менше кешу на ядро (залежить від SKU)
- більш складну NUMA-поведінку на мульти-сокетних системах (рідше в домашніх умовах)
Такти: затримки і хвостова продуктивність
Одноядерна продуктивність все ще важлива для:
- шляхів пакетної обробки PFSense/OPNsense у деяких конфігураціях
- ігрових серверів
- деяких шляхів зберігання (контрольні суми, стиснення, шифрування) залежно від налаштувань
- будь-якого навантаження з послідовною критичною ділянкою
У змішаних навантаженнях хвостова затримка вбиває. CPU, що швидко підвищує частоту на кількох ядрах, одночасно тримаючи інші зайнятими, може відчуватися краще за «більше ядер, нижчий турбо», навіть якщо бенчмарк показує інше.
Кеш: невидимий фактор продуктивності
L3 кеш — тихий MVP для щільності віртуалізації. Багато ВМ означає багато робочих наборів. Промахи кешу призводять до трафіку памʼяті; трафік памʼяті — до конкуренції; конкуренція — до спайків і «рандомності».
Правило: якщо ви запускаєте багато сервісів з помірним використанням CPU (типова домашня лабораторія), віддавайте перевагу CPU з гідним L3 і стабільною поведінкою всіх ядер, а не лише пік-бусту.
AES, AVX та набори інструкцій, що змінюють правила
AES-NI (і родичі): якщо ви шифруєте — це важливо
AES-NI прискорює поширені криптографічні операції. Якщо ви використовуєте:
- ZFS native encryption
- LUKS/dm-crypt
- VPN-тунелі (WireGuard більше про операції з кривими; IPsec/OpenVPN можуть балансувати на AES)
- велику кількість TLS-термінацій (реверс-проксі, внутрішній PKI, сервісні сітки)
…то AES-NI може перетворити «шифрування обмежує CPU» на «I/O-обмеження — нормальне життя». Це також зменшує джиттер: шифрування без прискорення може відбирати CPU у найневідповідніший момент.
AVX2/AVX-512: продуктивність з умовами
AVX може значно прискорити певні обчислення. Він також може:
- збільшувати енергоспоживання
- призводити до нижчих частот CPU під тривалим AVX-навантаженням
- створювати загадку «чому хост повільніший, коли та ВМ працює»
У домашньому середовищі, де одна ВМ може монополізувати хост, AVX‑важкі завдання можуть стати «шумним сусідом». Не бійтеся AVX. Розумійте його і, за потреби, ізолюйте (pinning CPU, квоти, окремий хост).
CRC32, carryless multiply і міф «CPU для зберігання»
Стеки зберігання використовують різні інструкції для контрольних сум і стиснення. ZFS, наприклад, отримує користь від потужного CPU для контрольних сум і стиснення, але більшість домашніх систем обмежені дисками чи NIC до того, як CPU стане вузьким місцем. Виняток — коли ви вмикаєте дорогі режими стиснення, сильне шифрування або працюєте з 10/25GbE і швидкими SSD. Тоді CPU стає двигуном зберігання.
Топологія, SMT, NUMA та тихі помилки планувальника
CPU — це не рівне поле з ідентичними ядрами. Сучасні системи мають SMT (Hyper-Threading), спільні кеші, чіплети та інколи гетерогенні ядра. Гіпервізори і планувальники хоста роблять усе можливе. Вони також іноді «ввічливо брешуть».
SMT: додатковий пропуск, інколи гірші затримки
SMT може збільшити пропускну здатність для змішаних навантажень. Але якщо ви привʼязуєте vCPU один-до-одного з pCPU і забуваєте про SMT, можна випадково привʼязати дві активні vCPU до сестринських потоків одного фізичного ядра. Так виникає «ВМ має виділені ядра, але все одно підтормажує».
NUMA: переважно серверна проблема, поки не стане вашою
На односокетних споживчих платформах ефекти NUMA є, але менш драматичні. На мульти-сокетних системах або в робочих станціях з великою кількістю ядер NUMA‑помилки можуть подвоїти затримку памʼяті для ВМ. Якщо ви купуєте вживаний двосокетний сервер, навчіться основам NUMA або погодьтеся на те, що деякі ВМ матимуть дивні проблеми з продуктивністю.
Управління живленням: тихий саботаж
Зміна частот чудова для ноутбуків. На хості ВМ «powersave» може виглядати як випадкові спайки затримки. Balanced режим може бути прийнятним, але потрібно перевірити, що дійсно робить хост. Якщо ваш хост — це маленький сервер, ставтеся до нього як до сервера.
Жарт #2: Governor «powersave» на хості ВМ — це як відправити вашу базу даних на йога-рекол, вона знайде внутрішній спокій саме тоді, коли вам потрібні відповіді.
Міри безпеки: податок на продуктивність з доказами
Spectre, Meltdown, L1TF, MDS, SSB, Retbleed — обирайте свої акроніми. Міри захисту часто впливають на оверхед системних викликів, контекстні переключення та шляхи віртуалізації.
Операційні поради:
- Не вимикайте mitigations бездумно. Домашні лабораторії теж піддаються атакам. Ваші router VM і NAS VM не особливі сніжинки.
- Знайте покоління CPU. Деякі покоління більше страждають від окремих mitigations.
- Вимірюйте до і після. Міри не завжди «повільні». Деякі навантаження ледь помітять різницю.
Одна парафразована ідея від легенди операцій: «Надія — не стратегія.» — пересказ думки Gene Kranz (дисципліна місії). У термінах віртуалізації: не надягайтеся, що функція є — перевіряйте її на вашому конкретному обладнанні і прошивці.
Практичні завдання: команди, вивід, рішення (12+)
Це перевірки, які я реально виконую, коли діагностую хост, оцінюю покупку або підтверджую зміну в BIOS. Кожне завдання має: команду, типове значення виводу і рішення, яке ви приймаєте.
Завдання 1: Підтвердити прапори віртуалізації CPU (VT-x/AMD-V)
cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|CPU\(s\)'
CPU(s): 16
Model name: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
Virtualization: VT-x
Значення: «Virtualization: VT-x» означає, що ядро бачить підтримку апаратної віртуалізації.
Рішення: Якщо цього немає (або поле порожнє), перевірте налаштування BIOS/UEFI для Intel VT-x/AMD SVM. Якщо й досі немає — CPU/платформа можуть не підтримувати це або функцію заблоковано.
Завдання 2: Підтвердити EPT/NPT (друге рівневе транслювання)
cr0x@server:~$ grep -Eo 'vmx|svm|ept|npt' /proc/cpuinfo | sort | uniq -c
16 ept
16 vmx
Значення: Наявність ept (Intel) або npt (AMD) вказує на підтримку SLAT, критичну для продуктивності.
Рішення: Якщо у вас є VT-x/AMD-V, але немає EPT/NPT, вважайте цей CPU поганим вибором для сучасних робочих навантажень.
Завдання 3: Перевірити, що модулі KVM завантажені і доступні
cr0x@server:~$ lsmod | egrep 'kvm|kvm_intel|kvm_amd'
kvm_intel 372736 0
kvm 1032192 1 kvm_intel
irqbypass 16384 1 kvm
Значення: KVM активний; irqbypass часто зʼявляється у контексті віртуалізації.
Рішення: Якщо модулі KVM не завантажуються, перевірте налаштування BIOS віртуалізації і dmesg на предмет повідомлень «disabled by bios».
Завдання 4: Перевірити, чи IOMMU увімкнено в ядрі
cr0x@server:~$ dmesg | egrep -i 'iommu|dmari|amd-vi' | head -n 8
[ 0.842311] DMAR: IOMMU enabled
[ 0.842451] DMAR: Intel(R) Virtualization Technology for Directed I/O
[ 0.924113] DMAR: Interrupt remapping enabled
Значення: IOMMU увімкнено; interrupt remapping — добрий знак для безпечного passthrough.
Рішення: Якщо ви не бачите «IOMMU enabled», ймовірно треба включити VT-d/AMD-Vi в BIOS і додати параметри ядра (наприклад, intel_iommu=on або amd_iommu=on).
Завдання 5: Підтвердити наявність параметрів IOMMU в cmdline ядра
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0 root=UUID=... ro quiet intel_iommu=on iommu=pt
Значення: intel_iommu=on вмикає IOMMU; iommu=pt часто покращує продуктивність хоста, використовуючи passthrough mapping для пристроїв хоста.
Рішення: Якщо потрібен passthrough, додайте потрібні прапори і перебудуйте конфігурацію завантажувача. Якщо passthrough не потрібен, можна також увімкнути IOMMU для ізоляції, але вимірюйте регресії.
Завдання 6: Переглянути IOMMU групи (мовірність passthrough)
cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:"; lspci -nns $(ls "$g/devices" | sed 's/^/0000:/'); echo; done | head -n 30
IOMMU Group 0:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e30]
IOMMU Group 1:
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]
IOMMU Group 2:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1f82]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa]
Значення: Пристрої в одній групі не можна безпечно розділити без ACS. GPU з аудіо-інтерфейсом в одній групі — нормально і працездатно.
Рішення: Якщо цільовий пристрій ділить групу з тим, що потрібно хосту (USB-контролер, SATA), плануйте інший слот, іншу материнську плату або відмовтеся від passthrough.
Завдання 7: Переконатися, що гіпервізор може показати фічі CPU гістьовим ОС
cr0x@server:~$ virsh capabilities | egrep -n 'model|feature' | head -n 12
32: Skylake-Client
41: Значення: libvirt бачить моделі CPU і фічі, які може представити ВМ.
Рішення: Для ВМ, чутливих до продуктивності, віддавайте перевагу «host-passthrough» режиму CPU (якщо не потрібно міграцій). Для змішаних кластерів використовуйте сталий базовий модель CPU.
Завдання 8: Перевірити поточний governor CPU (часто причини джиттера тут)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Значення: Хост надає пріоритет енергозбереженню, що може вводити затримки й уповільнення.
Рішення: Розгляньте перехід на performance на виділеному хості для ВМ, особливо якщо бачите джиттер. Виміряйте споживання та термальні показники.
Завдання 9: Тимчасово перемкнути governor на performance і перевірити
cr0x@server:~$ sudo apt-get install -y linux-cpupower
Reading package lists... Done
...
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
...
cr0x@server:~$ cpupower frequency-info | egrep -i 'governor|current policy' | head -n 6
current policy: frequency should be within 800 MHz and 4.70 GHz.
The governor "performance" may decide which speed to use
Значення: Governor змінено; показано діапазон політики.
Рішення: Якщо латентність ВМ покращиться, зробіть зміну постійною через інструменти управління живленням дистрибутива.
Завдання 10: Перевірити своп на хості (часто помилково вважають «слабким CPU»)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 31Gi 26Gi 1.2Gi 3.1Gi 3.8Gi 1.6Gi
Swap: 16Gi 6.5Gi 9.5Gi
Значення: Активне використання swap під навантаженням — червоний прапор для продуктивності ВМ і відгуку хоста.
Рішення: Зменшіть overcommit памʼяті, додайте RAM, налаштуйте політику ballooning для ВМ або перемістіть памʼяттєво‑важкі сервіси з цього хоста. Оновлення CPU не вирішить проблему свопу.
Завдання 11: Виявити steal time всередині ВМ (конкуренція на хості)
cr0x@server:~$ mpstat 1 5
Linux 6.5.0 (vm01) 01/12/2026 _x86_64_ (4 CPU)
12:01:02 PM all %usr %nice %sys %iowait %irq %soft %steal %idle
12:01:03 PM all 12.00 0.00 4.00 0.00 0.00 1.00 18.00 65.00
Значення: %steal вказує, що ВМ хотіла CPU, але хост не запланував її. Це конкуренція, а не «Linux повільний».
Рішення: Зменшіть overcommit, привʼяжіть vCPU, зарезервуйте CPU для критичних ВМ або додайте ядра. Також перевірте наявність «шумного сусіда» ВМ.
Завдання 12: Знайти гарячі точки переривань (вузькі місця NIC/дисків, замасковані як CPU)
cr0x@server:~$ cat /proc/interrupts | head -n 12
CPU0 CPU1 CPU2 CPU3
24: 987654 0 0 0 IR-PCI-MSI 327680-edge nvme0q0
25: 0 876543 0 0 IR-PCI-MSI 327681-edge nvme0q1
34: 4321098 0 0 0 IR-PCI-MSI 524288-edge enp3s0-rx-0
Значення: Одне CPU обробляє більшість переривань для високотрафікового пристрою — це може створювати затримки й знижувати пропускну здатність ВМ.
Рішення: Переконайтеся, що irqbalance працює (або вручну привʼяжіть переривання), розподіліть черги по CPU і уникайте привʼязування критичних ВМ до ядра з великою кількістю переривань.
Завдання 13: Перевірити, чи застосовано мікрокод (стабільність і міри)
cr0x@server:~$ dmesg | egrep -i 'microcode' | tail -n 5
[ 0.321987] microcode: microcode updated early to revision 0x000000f0, date = 2023-09-12
Значення: Оновлення мікрокоду може виправити errata, покращити стабільність і впливати на поведінку міри захисту.
Рішення: Тримайте пакети з мікрокодом актуальними. Якщо бачите дивні віртуалізаційні помилки, перевірте, що ви не використовуєте застарілий мікрокод.
Завдання 14: Перевірити статус міри захисту (очікування продуктивності)
cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -n 10
/sys/devices/system/cpu/vulnerabilities/meltdown: Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS: disabled; STIBP: conditional; RSB filling
Значення: Ядро повідомляє, які міри захисту активні. Деякі з них сильніше впливають на продуктивність ВМ.
Рішення: Якщо після оновлень зʼявився регрес у бенчмарках, перевірте цей вивід. Не гадати. Вирішуйте, приймати «податок» чи перепроектувати (менше VM exits, краще I/O, інше покоління CPU).
Завдання 15: Виміряти модель CPU і прапори для кожної ВМ (приклад QEMU/KVM)
cr0x@server:~$ sudo virsh dumpxml vm01 | egrep -n 'cpu mode|model|feature' | head -n 20
57:
Значення: host-passthrough відкриває фічі хостового CPU для гостя, зазвичай максимально підвищуючи продуктивність.
Рішення: Якщо потрібна жива міграція між різними CPU, не використовуйте host-passthrough; обирайте сумісну модель CPU. Якщо ви не мігруєте — host-passthrough зазвичай правильний вибір.
Швидкий план діагностики
Коли «ВМ повільні», не починайте з читання маркетингових сторінок про CPU. Почніть з безжальної триажі для виявлення вузького місця.
Перше: визначте, це планування CPU, тиск памʼяті чи I/O
- Завантаження хоста і черга запуску: чи хост CPU-сатурований або просто «зайнятий»?
- Активність свопа: якщо свопиться — зупиніться. Виправте памʼять спочатку.
- I/O wait: якщо iowait високий, функції CPU не є обмеженням.
Друге: перевірте лічильники, специфічні для віртуалізації
- VM steal time: всередині гостя шукайте
%steal. - VM exits (опосередковано): перевірте, чи навантаження не викликає надмірні syscalls, переривання або емулювання (наприклад, неправильно налаштований virtio).
- Розподіл переривань: гарячі IRQ на одному ядрі можуть виглядати як «рандомні» гальма.
Третє: перевірте прошивку і перемикачі функцій
- VT-x/AMD-V увімкнено
- VT-d/AMD-Vi увімкнено
- SR-IOV увімкнено (якщо потрібно)
- Оновлений BIOS і мікрокод
- Режим управління живленням придатний для хоста
Четверте: вирішіть, чи потрібен новий CPU, чи новий план
- Якщо відбувається swap, купуйте RAM або зменшуйте overcommit.
- Якщо домінує iowait, ремонтуйте сховище/мережу (черги, драйвери, вибір пристрою).
- Якщо steal time високий, додайте ядра, зменшіть консолідацію або ізолюйте шумні ВМ.
- Якщо passthrough не вдається — ймовірніше вам потрібна інша материнська плата, а не CPU.
Три корпоративні історії з практики
Інцидент через неправильне припущення: «VT-d увімкнено, отже passthrough працюватиме.»
Невелика інфраструктурна команда вирішила стандартизувати компактну робочу станцію для віддаленого офісу. Мета була проста: кілька ВМ плюс GPU passthrough для Windows‑навантаження. Вони перевірили CPU: підтримує віртуалізацію, підтримує VT-d. Все, готово, правда?
Вони зібрали перший екземпляр, встановили гіпервізор, увімкнули VT-d у BIOS і виконали стандартні перевірки IOMMU. IOMMU було увімкнено. Усі заспокоїлися. Потім вони спробували присвоїти GPU ВМ і отримали проблеми: GPU опинився в тій самій IOMMU групі з USB-контролером і PCIe мостом, які також обслуговують критичний пристрій на платі. Присвоєння всієї групи означало б відірвати потрібний хосту пристрій. Не дуже приємний варіант, коли хосту потрібен цей контролер для надійного завантаження.
Команда спершу намагалася «лікувати Linux». Вони пробували патчі ACS override. Частково працювало, поки не переставало — випадкові скидання під навантаженням і періодичні DMA-фейли, що виглядали як проблеми драйвера. Це не був драйвер. Це топологія PCIe платформи і слабкі межі ізоляції.
Вони врешті замінили материнську плату на ту, що має кращу проводку слотів PCIe і адекватну поведінку ACS. Той самий CPU. Та сама GPU. І все запрацювало. Урок не в «passthrough складний». Урок у тому, що підтримка функцій CPU потрібна, але тіла ховаються на платі.
Оптимізація, що повернулася бумерангом: «Даємо pinning всьому заради продуктивності.»
Інша команда керувала кластером віртуалізації зі змішаними веб‑сервісами, логуванням і кількома чутливими до затримки ВМ. Інженер вирішив «серйозно підходити»: CPU pinning, isolcpus, tuned профілі — повний набір. На папері виглядало чудово — виділені ядра для важливих ВМ, менше переключень контексту, більше детермінізму.
Насправді продуктивність погіршилася. Чутливі ВМ час від часу зависали, і навантаження softirq хоста різко зросло. Інженер уважно привʼязав vCPU, але забув, що переривання і ядра ядра все одно потребують CPU. Гірше того, черга високотрафікового NIC і NVMe інтеррупт опинилися на тих же «ізольованих» сестринських ядрах через дефолтну IRQ affinity.
Результат класичний: ВМ мала «виділені» CPU, але виділене CPU займалося перериваннями і хостовими задачами. Pinning зменшив здатність планувальника згладжувати піки, тому спайки стали гострішими. Користувачі помітили. Grafana перетворилася на містичний хорор.
Вони виправили проблему, помʼякшивши агресивний pinning, явно задавши IRQ affinity і зарезервувавши кілька ядер для хоста. Ефект був менш «чистим», ніж діаграма, але стабільним. Налаштування продуктивності — це переговори з реальністю; реальність не читає ваш runbook.
Скучна, але правильна практика, що врятувала ситуацію: базові моделі CPU і контроль змін
Середня компанія керувала середовищем віртуалізації, де була важлива жива міграція. У них були різні покоління CPU, бо оновлення апаратури відбувається хвилями. Рано вони навчилися, що режим «host-passthrough» чудовий, поки не треба мігрувати ВМ на хост з трохи іншим набором фіч.
Тож вони зробили нудну, але правильну річ: стандартизували моделі CPU для ВМ на консервативному базисі і документували необхідні прапори CPU. Вели чекліст перед оновленням BIOS, версії мікрокоду і мали «канаркову ВМ», яка запускала невеликий набір тестів після змін.
Одного вікенду хост впав і пакет ВМ потрібно було перемістити. Кластер зробив це без драм. Базовий набір фіч уникнув помилок міграції, а канарка вже перевірила новий хост раніше. Ніякого героїчного налагодження о 2:00 — лише нормальна експлуатація.
Не було гламурно. Було правильно. І в інженерії надійності «нудно» — це похвала.
Поширені помилки: симптом → корінь → виправлення
1) GPU passthrough не стартує; QEMU скаржиться на IOMMU
Симптоми: ВМ не завантажується з passthrough; в логах згадується DMAR/IOMMU, «VFIO: No IOMMU» або проблеми скидання пристрою.
Корінь: VT-d/AMD-Vi вимкнено в BIOS, відсутні параметри ядра або IOMMU групи не ізольовані.
Виправлення: Увімкніть VT-d/AMD-Vi в BIOS; додайте intel_iommu=on або amd_iommu=on; перевірте IOMMU групи; якщо групи погані — змініть материнську плату/слот або перегляньте passthrough.
2) ВМ підтормажують під навантаженням, хоча CPU «низько»
Симптоми: Інтерактивні затримки, аудіоскавчання, втрата пакетів, але середній CPU виглядає нормальним.
Корінь: Частотне масштабування CPU (powersave), буря переривань на одному ядрі або steal time через oversubscription.
Виправлення: Встановіть governor performance; розподіліть IRQ; зарезервуйте ядра для хоста; зменшіть oversubscription; виміряйте %steal у ВМ.
3) Продуктивність зберігання падає при увімкненні шифрування/стиснення
Симптоми: Високе навантаження CPU в системних потоках, зростання I/O latency, пропускна здатність далеко від меж дисків/NIC.
Корінь: Відсутність або погано доступне AES прискорення для гостей, або CPU став вузьким місцем із-за дорогих налаштувань.
Виправлення: Перевірте прапори AES-NI/VAES на хості і в гості; використовуйте host-passthrough CPU режим де потрібно; налагодьте стиснення; розгляньте швидший CPU або стратегічне вивантаження.
4) Жива міграція не вдається з помилкою «CPU incompatible»
Симптоми: Міграція відхилена; помилка згадує відсутні фічі CPU.
Корінь: Використовується host-passthrough або відкриті фічі, яких немає на хості-цілі.
Виправлення: Стандартизуйте базову модель CPU; маскуйте фічі; тримайте хости в сумісних сімействах CPU, якщо міграція обовʼязкова.
5) Випадкові падіння ВМ після «оптимізації продуктивності»
Симптоми: Іноді скидання, зависання, дрейф часу або дивні помилки пристроїв після pinning/тюнінгу.
Корінь: Надто агресивна ізоляція CPU, неправильне привʼязування IRQ, відсутність ядер для хостових задач або нестабільні настройки undervolt/overclock.
Виправлення: Відкатити екзотичні налаштування; виділити ядра для хостової адміністрації; переконатися, що мікрокод актуальний; вимкнути розгін для серверної машини.
6) Пропускна здатність мережі низька, хоча CPU сильний
Симптоми: Низька пропускна здатність, високий softirq, втрата пакетів, одне ядро завантажене повністю.
Корінь: Неправильна конфігурація virtio, недостатньо черг, проблеми з IRQ affinity або відсутність offloads/SR-IOV там, де потрібні.
Виправлення: Використовуйте virtio-net з multiqueue; підтвердіть розподіл IRQ; розгляньте SR-IOV або passthrough NIC для близького до лінійної продуктивності з малою витратою CPU.
Чеклісти / покроковий план
Покроково: як вибрати CPU/платформу для домашнього гіпервізора
- Визначте «обовʼязкові» функції. Passthrough GPU? HBA passthrough? 10GbE маршрутизація? Шифрування скрізь? Якщо так — пріоритет IOMMU поведінка і AES прискорення.
- Обирайте платформу, а не лише CPU. Розклад PCIe на материнській платі, зрілість BIOS і підтримка чипсета визначатимуть ваше повсякденне життя.
- Перевірте SLAT. Переконайтеся в EPT (Intel) або NPT (AMD). Розглядайте це як обовʼязкове для сучасної віртуалізації.
- Визначте позицію щодо міграцій. Один хост: host-passthrough підходить. Кілька хостів з міграцією: стандартизуйте модель/фічі CPU.
- Розмір RAM важливіше за ядра. Якщо можете дозволити лише одне оновлення, RAM запобігає найгіршим збоєм продуктивності.
- Виділіть ядра для хоста. Залиште запас для переривань, ZFS і самого гіпервізора.
- Плануйте тепловий режим і живлення. CPU, що тротлиться, — це CPU, який вам бреше.
Покроково: перевірка нового хоста перед міграцією сервісів
- Оновіть BIOS/UEFI до стабільної версії.
- Встановіть пакети мікрокоду і підтвердіть у dmesg.
- Увімкніть VT-x/AMD-V та VT-d/AMD-Vi у BIOS.
- Завантажтесь з прапорами IOMMU в kernel cmdline, якщо потрібен passthrough.
- Перевірте IOMMU групи і підтвердіть, що цільові пристрої можна ізолювати.
- Встановіть відомий добрий CPU governor; виміряйте джиттер.
- Запустіть канаркову ВМ: тест мережі, диска, CPU і цикл перезавантажень.
- Тільки після цього мігруйте реальні сервіси.
Покроково: стабілізація продуктивності на існуючому хості
- Перевірте використання свопу і усуньте тиск памʼяті в першу чергу.
- Перевірте %steal у ключових ВМ, щоб виявити oversubscription.
- Перевірте iowait, щоб зʼясувати, чи сховище є вузьким місцем.
- Проаналізуйте переривання на наявність гарячих точок; виправте розподіл IRQ.
- Переконайтеся в коректності драйверів virtio і налаштувань multiqueue.
- Розгляньте pinning тільки якщо можете контролювати переривання і виділити ядра для хоста.
FAQ
1) Чи потрібен VT-x/AMD-V для домашньої віртуалізації?
Так, для сучасних гіпервізорів і адекватної продуктивності. Без нього ви або не зможете запускати певні гіпервізори, або отримаєте повільну/обмежену роботу. Вважайте це обовʼязковим.
2) Чи дійсно EPT/NPT так важливі?
Так. SLAT (EPT/NPT) — один з найзначніших факторів продуктивності для ВМ. Якщо ви оцінюєте старі CPU — ця фіча має вирішальне значення.
3) Я увімкнув VT-d/AMD-Vi. Чому passthrough все одно не працює?
Тому що IOMMU групи і топологія PCIe материнської плати визначають, що можна ізолювати. Перевірте також параметри ядра, interrupt remapping і чи підтримує пристрій reset, потрібний для VFIO.
4) Що обирати: більше ядер чи вищі такти?
Для типової домашньої лабораторії (багато сервісів, помірне навантаження) більше ядер з гідним кешем і стабільним all-core boost зазвичай кращі. Для декількох чутливих до затримки ВМ кращі вищі стійкі такти. Якщо ви хочете і те, й інше — шукайте вищий бюджет.
5) SMT/Hyper-Threading допомагає віртуалізації?
Часто так для пропускної здатності, іноді ні для передбачуваності затримок. Якщо ви робите pinning, врахуйте SMT, щоб випадково не привʼязати два важких vCPU до сусідніх потоків одного фізичного ядра.
6) Чи потрібен AVX-512?
Тільки якщо ви виконуєте завдання, що реально його використовують. Для багатьох домашніх навантажень AVX-512 неактуальний. Він також може впливати на частоту. Купуйте його з причини, а не заради реклами.
7) AES-NI важливий, якщо я не запускаю VPN?
Все одно може бути важливим. Шифрування зʼявляється в шифруванні даних на диску, бекапах, TLS і іноді в ланцюгах перевірки збереження/стиснення. Якщо ви шифруєте дані у стані спокою, варто звернути увагу на прискорення AES.
8) Чи варто вимкнути міри безпеки CPU, щоб повернути продуктивність?
Зазвичай ні. Якщо ви бенчмаркуєте і розумієте ризики, можете тестувати. Для реальних сервісів — навіть домашніх — тримайте міри включеними і вирішуйте проблему, знижуючи конкуренцію, покращуючи I/O або оновлюючи обладнання.
9) IOMMU корисне, навіть якщо я не роблю passthrough?
Так — для ізоляції DMA і загальної безпекової позиції, але це може додати складності. Якщо воно не потрібне, можна залишити вимкненим. Якщо може знадобитися пізніше — увімкніть заздалегідь і перевірте стабільність.
10) Чи може «серверний» CPU бути гіршим за споживчий для домашньої віртуалізації?
Так. Старі серверні CPU можуть мати багато ядер, але слабшу одноядерну продуктивність, більше енергоспоживання і сильніший вплив міри захисту. Вони можуть бути чудові для сукупної пропускної здатності; вони можуть здаватися повільними для змішаних інтерактивних навантажень.
Наступні кроки, які реально можна зробити
Якщо ви хочете найкоротший шлях до кращої домашньої віртуалізації:
- Запустіть перевірочні команди вище на поточному хості: SLAT, IOMMU, governor, swap, interrupts, %steal.
- Виправте дешеві проблеми спочатку: встановіть адекватний governor, припиніть свопінг, налаштуйте virtio і розподіл IRQ.
- Якщо потрібен passthrough, перевірте IOMMU групи перед будь-якою покупкою. Новий CPU не виправить материнську плату, що не ізолює пристрої.
- При виборі заліза пріоритезуйте: EPT/NPT + надійне IOMMU + достатня кількість ядер + достатній кеш + достатній обʼєм RAM на платформі.
- Вимірюйте після кожної зміни. Домашні лабораторії — це джерело міфів про продуктивність; вимірювання — спосіб їх уникнути.