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: if the flags passed to the guest are missing, the QEMU process stops.
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 and no AES-NI) | Widest (any host) | Lowest |
| x86-64-v2-AES | SSE4.2, POPCNT, AES-NI — Westmere and Opteron 6200 (about 2010–2011). Haswell and Zen 1 are v3 | 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/CD/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 | Same CPU model and microcode | Maximum (native) |
The x86-64-v2/v3/v4 models are standardised microarchitecture levels (psABI), independent of vendor. That makes them the best choice for a mixed Intel+AMD cluster, as long as every node meets the level — although the Proxmox documentation states that live migration between Intel and AMD CPUs is not guaranteed to work.
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 the same CPU model and the same microcode version. The trade-off is portability: live migration to a host with a different (older) CPU or a different microcode version can fail — if the target CPU lacks flags passed to the guest, the QEMU process will stop.
- 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