// Poradnik techniczny // CPU · QEMU/KVM Aktualizacja:

Wybór typu CPU w Proxmox:
QEMU vs host vs x86-64-v4

Ustawienie typu procesora wirtualnego (vCPU) w Proxmox VE to jeden z najczęściej źle dobranych parametrów. Wpływa jednocześnie na wydajność, dostępność instrukcji (AVX-512, AES-NI) oraz możliwość migracji na żywo między hostami. Wyjaśniamy, co naprawdę robią poszczególne modele.

// 01 · Czym jest „typ CPU”

Wirtualny CPU to kontrakt instrukcji

QEMU/KVM nie emuluje procesora — maszyna wirtualna wykonuje instrukcje bezpośrednio na fizycznym rdzeniu (sprzętowa wirtualizacja Intel VT-x / AMD-V). „Typ CPU” w konfiguracji VM decyduje wyłącznie o tym, jaki zestaw cech (CPU flags) i jaką nazwę modelu hypervisor prezentuje gościowi przez instrukcję CPUID.

To rozróżnienie jest kluczowe: gość widzi i może użyć tylko tych instrukcji, które zostały mu zadeklarowane. Jeśli zadeklarujemy zbyt mało — tracimy wydajność (brak AVX, AES-NI). Jeśli zadeklarujemy więcej, niż ma host docelowy, migracja na żywo się nie powiedzie: gdy brakuje flag przekazanych gościowi, proces QEMU zostanie zatrzymany.

ℹ️

W Proxmox typ CPU ustawiasz per-VM: VM → Hardware → Processors → Type, lub w CLI qm set <vmid> --cpu <model>.

// 02 · Główne modele

Porównanie typów vCPU

Typ CPUCo prezentuje gościowiMigracja na żywoWydajność
kvm64 / qemu64Bazowy model bezpieczny — minimalny zestaw flag (bez AVX i bez AES-NI)Najszersza (każdy host)Najniższa
x86-64-v2-AESSSE4.2, POPCNT, AES-NI — Westmere i Opteron 6200 (około 2010–2011). Od Haswell i Zen 1 jest v3Bardzo szerokaDobra dla większości
x86-64-v3AVX, AVX2, BMI1/2, FMA — Haswell/Zen 1 i nowszeKlaster z CPU ≥ tego poziomuWysoka
x86-64-v4AVX-512 (F/BW/CD/DQ/VL) — Skylake-SP, Zen 4/5Tylko jednorodny klaster v4Najwyższa (przy AVX-512)
host1:1 wszystkie flagi fizycznego CPU hostaTen sam model CPU i mikrokodMaksymalna (natywna)

Modele x86-64-v2/v3/v4 to ustandaryzowane poziomy mikroarchitektury (psABI), niezależne od producenta. Dlatego w mieszanym klastrze Intel+AMD to najlepszy wybór, o ile wszystkie węzły spełniają dany poziom — choć dokumentacja Proxmoxa zastrzega, że migracja na żywo między procesorami Intel i AMD nie jest gwarantowana.

// 03 · host vs reszta

Kiedy host, a kiedy poziom vX

Typ host przekazuje gościowi pełny zestaw instrukcji fizycznego procesora — to najwydajniejsza opcja, idealna gdy VM nigdy nie będzie migrowana na żywo lub gdy cały klaster ma ten sam model CPU i tę samą wersję mikrokodu. Tracisz jednak przenośność: migracja na żywo na host z innym (starszym) CPU albo z innym mikrokodem może się nie udać — jeśli docelowy procesor nie ma flag przekazanych gościowi, proces QEMU zostanie zatrzymany.

  • Wybierz host: klaster z jednakowymi serwerami, obciążenia HPC/AI, bazy danych korzystające z AVX-512, brak wymogu migracji na żywo między różnymi generacjami.
  • Wybierz x86-64-v3: rozsądny domyślny wybór dla mieszanego, nowoczesnego klastra — daje AVX2 i zachowuje migrację na żywo.
  • Wybierz x86-64-v4: jednorodny klaster Zen 4/5 lub Xeon SP, gdzie zależy Ci na AVX-512 przy zachowaniu migracji w obrębie tego poziomu.
  • Unikaj kvm64 w produkcji: brak AES-NI i AVX potrafi spowolnić szyfrowanie i obliczenia o rzędy wielkości.
⚠️

Pułapka migracji: jeśli VM wystartowała z typem host na nowym EPYC, nie zmigrujesz jej na żywo na starszy węzeł — gość „widzi” instrukcje, których docelowy CPU nie ma. Dla mieszanych klastrów ustaw najniższy wspólny poziom (np. v3).

// 04 · AVX-512 i bazy danych

Dlaczego flagi mają znaczenie

Nowoczesne obciążenia realnie korzystają z rozszerzeń wektorowych: PostgreSQL i silniki kolumnowe przyspieszają na AVX2/AVX-512, biblioteki AI (oneDNN, OpenBLAS) wykrywają AVX-512 w runtime, a szyfrowanie TLS/dysków bez AES-NI obciąża CPU wielokrotnie bardziej. Ukrycie tych flag (np. przez kvm64) sprawia, że oprogramowanie wybiera wolne ścieżki kodu.

Z drugiej strony AVX-512 bywa „kosztowne” — intensywne instrukcje mogą obniżyć takt (frequency offset). Dla baz licencjonowanych per-core (Oracle EE, MS SQL Enterprise) liczy się wysoki, stabilny zegar — stąd dobieramy EPYC 9175F z typem host na dedykowanych węzłach, by oddać gościowi pełnię możliwości CPU.

💡

Nasza rekomendacja domyślna: dla typowego mieszanego klastra Proxmox ustaw x86-64-v3 (AVX2 + zachowana migracja). Dla jednorodnych, wydajnościowych węzłów — host lub x86-64-v4.

Zaprojektujemy Twój klaster Proxmox

Dobierzemy typy CPU, poziomy mikroarchitektury i topologię węzłów pod Twoje obciążenia — z zachowaniem migracji na żywo tam, gdzie jej potrzebujesz.

⚡ Bezpłatna konsultacja → Kontenery LXC w Proxmox