VM CPU: types, NUMA, pinning, limits

Why this matters in production

CPU configuration affects both performance and operability. The wrong choice produces VMs that perform well until you try to migrate them, or VMs that migrate easily but perform badly.

CPU model choices

qm set 100 --cpu x86-64-v3

CPU flags for live migration

When a VM uses host and migrates from a Skylake host to a Cascade Lake host, the migration succeeds but the destination may not have all the flags the source exposed. To migrate cleanly, the source’s feature set must be a subset of the destination’s.

Proxmox’s masking feature can strip features from a host CPU model to make it portable:

cat /etc/pve/cpu-models.conf

Sockets vs cores

A VM has vCPUs = sockets × cores × threads.

Most modern Linux and Windows handle multiple vCPUs per socket correctly. Sockets are mostly relevant for NUMA topology and licensing scenarios (some software is licensed per socket).

qm set 100 --sockets 2 --cores 4

NUMA

NUMA (Non-Uniform Memory Access) describes the memory hierarchy on multi-socket servers. A core has “local” memory (its own socket’s RAM) and “remote” memory (other sockets).

For a multi-socket host, NUMA-aware VMs perform better:

flowchart LR
  subgraph S0[Socket 0]
    C0[Core 0] --> M0[Memory 0]
  end
  subgraph S1[Socket 1]
    C1[Core 1] --> M1[Memory 1]
  end
  VM[VM] --> C0
  VM --> C1
  VM --> M0
  VM --> M1

Enable NUMA on a VM:

qm set 100 --numa 1

The guest kernel and userspace can then optimise memory placement.

CPU limits, units, and weights

Proxmox’s host scheduler can prioritise VMs:

qm set 100 --cpulimit 200

qm set 100 --cpuunits 2048

CPU pinning

For latency-sensitive workloads (databases, real-time), pin VM vCPUs to specific host cores. The VM uses only those cores; the host scheduler does not move them.

qm set 100 --affinity 0-3

Production considerations

Common mistakes

• cpu: host then trying to migrate to a host with different features.
• Allocating 32 vCPUs to a workload that uses 4.
• Pinning every VM, leaving no slack for failover.

Key takeaways

• Default CPU model: x86-64-v3. Use host only when needed and homogeneous.
• Sockets × cores × threads = vCPUs.
• Pin only latency-sensitive VMs; leave headroom for failover.

Knowledge check