A virtual CPU is an instruction contract
QEMU/KVM does not emulate a processor — the VM executes instructions directly on a physical core (hardware virtualisation via Intel VT-x / AMD-V). The "CPU type" in the VM config only decides which feature set (CPU flags) and which model name the hypervisor presents to the guest via the CPUID instruction.
This distinction is critical: the guest can only use the instructions it has been told about. Declare too few and you lose performance (no AVX, no AES-NI). Declare more than the target host actually has and live migration fails — or the guest crashes when it tries to use a missing instruction.
In Proxmox you set the CPU type per VM: VM → Hardware → Processors → Type, or via CLI qm set <vmid> --cpu <model>.
Comparing vCPU types
| CPU type | What it exposes to the guest | Live migration | Performance |
|---|---|---|---|
| kvm64 / qemu64 | Safe baseline — minimal flag set (no AVX, often no AES-NI) | Widest (any host) | Lowest |
| x86-64-v2-AES | SSE4.2, POPCNT, AES-NI — typical for servers after ~2013 | Very wide | Good for most |
| x86-64-v3 | AVX, AVX2, BMI1/2, FMA — Haswell/Zen 1 and newer | Cluster with CPUs ≥ this level | High |
| x86-64-v4 | AVX-512 (F/BW/DQ/VL) — Skylake-SP, Zen 4/5 | Homogeneous v4 cluster only | Highest (with AVX-512) |
| host | 1:1 all flags of the physical host CPU | Identical CPUs only | Maximum (native) |
The x86-64-v2/v3/v4 models are standardised microarchitecture levels (psABI), independent of vendor. This lets a mixed Intel+AMD cluster migrate VMs safely as long as every node meets the level.
When to use host, when a vX level
The host type passes the full instruction set of the physical CPU to the guest — the fastest option, ideal when a VM will never be live-migrated or when the entire cluster has identical CPUs. The trade-off is portability: live migration to a host with a different (older) CPU is blocked.
- Choose host: cluster of identical servers, HPC/AI workloads, databases leveraging AVX-512, no requirement for live migration across generations.
- Choose x86-64-v3: a sensible default for a modern mixed cluster — gives AVX2 and preserves live migration.
- Choose x86-64-v4: a homogeneous Zen 4/5 or Xeon SP cluster where you want AVX-512 while keeping migration within that level.
- Avoid kvm64 in production: missing AES-NI and AVX can slow encryption and compute by orders of magnitude.
Migration pitfall: if a VM started with the host type on a new EPYC, you cannot live-migrate it to an older node — the guest "sees" instructions the target CPU lacks. For mixed clusters, set the lowest common level (e.g. v3).
Why flags matter
Modern workloads genuinely use vector extensions: PostgreSQL and columnar engines accelerate with AVX2/AVX-512, AI libraries (oneDNN, OpenBLAS) detect AVX-512 at runtime, and TLS/disk encryption without AES-NI taxes the CPU many times harder. Hiding these flags (e.g. via kvm64) forces software onto slow code paths.
On the other hand, AVX-512 can be "expensive" — heavy instructions may lower clock speed (frequency offset). For per-core licensed databases (Oracle EE, MS SQL Enterprise) a high, stable clock matters most — which is why we pair the EPYC 9175F with the host type on dedicated nodes to give the guest the CPU's full capabilities.
Our default recommendation: for a typical mixed Proxmox cluster, set x86-64-v3 (AVX2 + preserved migration). For homogeneous, performance nodes — host or x86-64-v4.
We'll design your Proxmox cluster
We'll select CPU types, microarchitecture levels and node topology for your workloads — preserving live migration where you need it.
⚡ Free consultation → LXC containers in Proxmox