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ż realnie ma host docelowy — migracja na żywo się nie powiedzie albo gość wywróci się przy próbie użycia brakującej instrukcji.
W Proxmox typ CPU ustawiasz per-VM: VM → Hardware → Processors → Type, lub w CLI qm set <vmid> --cpu <model>.
Porównanie typów vCPU
| Typ CPU | Co prezentuje gościowi | Migracja na żywo | Wydajność |
|---|---|---|---|
| kvm64 / qemu64 | Bazowy model bezpieczny — minimalny zestaw flag (bez AVX, często bez AES-NI) | Najszersza (każdy host) | Najniższa |
| x86-64-v2-AES | SSE4.2, POPCNT, AES-NI — poziom typowy dla serwerów po ~2013 r. | Bardzo szeroka | Dobra dla większości |
| x86-64-v3 | AVX, AVX2, BMI1/2, FMA — Haswell/Zen 1 i nowsze | Klaster z CPU ≥ tego poziomu | Wysoka |
| x86-64-v4 | AVX-512 (F/BW/DQ/VL) — Skylake-SP, Zen 4/5 | Tylko jednorodny klaster v4 | Najwyższa (przy AVX-512) |
| host | 1:1 wszystkie flagi fizycznego CPU hosta | Tylko identyczne CPU | Maksymalna (natywna) |
Modele x86-64-v2/v3/v4 to ustandaryzowane poziomy mikroarchitektury (psABI), niezależne od producenta. Dzięki temu klaster Intel+AMD może bezpiecznie migrować VM, o ile wszystkie węzły spełniają dany poziom.
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 identyczne CPU. Tracisz jednak przenośność: migracja na żywo na host z innym (starszym) CPU jest zablokowana.
- 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).
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