CPU Pinning on Proxmox for Low-Latency VM Workloads

CPU pinning on Proxmox VE 9 assigns each vCPU thread in a VM to a specific physical CPU core, bypassing the Linux scheduler's normal load-balancing across all available cores. The result is consistent, predictable latency — the kind that matters for a Windows gaming VM with GPU passthrough, a real-time audio workstation, or an API server where p99 latency is a hard SLA. By the end of this guide your VM will have dedicated cores, the host scheduler will leave them alone, and you'll have three commands to verify the pinning is actually working.

Key Takeaways

• cpuaffinity: Run qm set <vmid> --cpuaffinity 4-7 to bind a QEMU process and all its threads to specific physical cores
• isolcpus matters: Without kernel-level core isolation, other processes can still preempt your pinned VM threads and cause jitter
• NUMA alignment: On EPYC or multi-socket systems, pin memory and CPUs to the same NUMA node or every memory access crosses the interconnect
• Live migration caveat: A VM with cpu: host set will not migrate to nodes with a different CPU microarchitecture — design for this upfront
• Not always worth it: General-purpose VMs and idle containers get no benefit; reserve pinning for sustained latency-sensitive workloads

What CPU Pinning Actually Does Under the Hood

Without pinning, the Linux Completely Fair Scheduler (CFS) migrates QEMU threads across physical cores continuously. This is efficient for throughput, but every thread migration causes L1 and L2 cache evictions on the core the thread just left and cold-cache misses on the core it lands on. For a 4K gaming session or a Postgres database handling sub-100 ms queries, those cache evictions translate to visible stutters or latency spikes.

cpuaffinity in Proxmox works by setting the cpuset cgroup for the entire QEMU process at VM start. Every thread QEMU spawns — vCPU threads, the I/O thread, device emulation threads — is constrained to the cores you specify. This is a process-level constraint rather than per-vCPU-thread pinning, but for the overwhelming majority of workloads it produces the same result with far less configuration overhead.

The kernel parameter isolcpus goes one step further: it removes specified cores from the scheduler's pool entirely. Nothing lands on an isolated core unless it explicitly requests affinity for that core. This is the difference between "I want my VM on cores 4-7" and "nothing else touches cores 4-7, ever."

How to Check Your NUMA Topology First

Understanding your hardware layout before picking cores is non-negotiable. Pinning to sibling hyperthreads on a saturated physical core, or crossing NUMA nodes, will make latency worse than no pinning.

lscpu --extended

Look at the CPU, CORE, SOCKET, and NODE columns. On an Intel Core i9-13900K, the 8 P-cores appear in hyperthreaded pairs — logical CPUs 0 and 16 share physical core 0, logical CPUs 1 and 17 share physical core 1, and so on. Always pin both hyperthreads of the same physical core together.

For NUMA topology on EPYC, Threadripper, or any dual-socket system:

numactl --hardware

On a single-socket consumer CPU this shows one node. On an EPYC 7302P, memory latency between the two NUMA nodes differs by roughly 30 ns — enough to add measurable jitter to database workloads.

For the most detailed view, install hwloc and render the full topology tree:

apt install hwloc -y
lstopo --no-io

This shows L3 cache domains. On AMD CPUs each CCX shares its own L3, so keep all pinned cores within a single CCX. On a Ryzen 9 7950X with two 8-core CCDs, keeping the VM to one CCD means all 8 cores share the same 32 MB L3 — a meaningful cache advantage for workloads with hot working sets.

How to Isolate Cores from the Host Kernel

This step is optional for lightly loaded hosts but strongly recommended for gaming or real-time workloads. Open the GRUB config:

nano /etc/default/grub

Append to GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=4-7,12-15 nohz_full=4-7,12-15 rcu_nocbs=4-7,12-15"

nohz_full stops the kernel from sending periodic timer interrupts to isolated cores, reducing jitter from hundreds of microseconds down to under 5 µs. rcu_nocbs offloads RCU callbacks off those same cores. All three options must reference the same core list.

Apply and reboot:

update-grub && reboot

After reboot, confirm isolation is active:

cat /sys/devices/system/cpu/isolated
# Expected output: 4-7,12-15

Leave at least 2 physical cores (plus their hyperthreads) for the Proxmox host OS. On a 12-core i9-12900K I keep cores 0-3 for Proxmox — the web UI, storage daemons, PBS sync jobs, and any lightweight LXC containers all run there without touching the VM's dedicated P-cores.

How to Configure cpuaffinity on a Proxmox VM

The cpuaffinity option accepts a comma-separated list of CPU IDs or ranges matching the logical CPU numbers from lscpu.

qm set 100 --cpuaffinity 4-7

Or edit the config file directly:

nano /etc/pve/qemu-server/100.conf

cpuaffinity: 4-7

The number of vCPUs in the VM does not need to exactly match the pinned range. If you pin to 4-7 (4 logical CPUs) and the VM has cores: 4,sockets: 1, each vCPU thread lands on one core. QEMU's I/O thread and device emulation threads are also constrained to that range, but they are lightweight and do not meaningfully compete with the vCPU threads.

For a gaming VM with 8 vCPUs across 4 physical P-cores with hyperthreading:

qm set 100 --cpuaffinity 4-7,12-15
qm set 100 --cores 8 --sockets 1
qm set 100 --cpu host

The cpu: host flag passes all physical CPU features directly to the guest, including AVX-512 and TSC invariant mode. Pair this with the full GPU passthrough configuration to get consistent frame times from a dedicated gaming or AI VM.

The tradeoff: cpu: host makes the VM non-migratable to hosts with a different CPU microarchitecture. If you're running a K3s Kubernetes cluster on Proxmox and need live migration across heterogeneous nodes, stick with cpu: x86-64-v3 and skip cpuaffinity on those VMs — portability matters more than the marginal latency gain.

NUMA Alignment: Bind Memory to the Right Node

On any multi-NUMA system, memory accesses that cross NUMA nodes add 20-40 ns per access. If your pinned cores are on NUMA node 0, bind the VM's RAM to node 0 as well.

Confirm which NUMA node owns your target cores:

numactl --hardware
# Look for "node 0 cpus:" and "node 1 cpus:" lines

Then add NUMA binding to the VM config:

nano /etc/pve/qemu-server/100.conf

cpuaffinity: 4-7
numa: 1
numa0: cpus=4-7,hostnodes=0,memory=16384,policy=bind

policy=bind hard-allocates guest RAM from NUMA node 0 only. If node 0 runs out of free memory the VM will fail to start rather than silently falling back to slower remote memory. policy=preferred is softer but can mask a memory budget mistake. Use bind so you know immediately if something is wrong.

On a properly aligned Proxmox EPYC system, STREAM TRIAD benchmark scores inside the guest improve 20-35% compared to unaligned placement. On real-world workloads like Postgres or ffmpeg encoding, expect 8-15% throughput improvement with p99 latency 30-50% lower.

Verifying the Pinning Is Actually Working

Start the VM and locate the QEMU process ID:

qm start 100
pgrep -a qemu-system-x86 | grep " 100 "

Check process-level affinity:

taskset -cp <pid>
# pid 12345's current affinity list: 4-7,12-15

Inspect individual thread placement:

ps -eLo pid,tid,psr,comm | grep qemu | head -20

The PSR column shows which physical CPU each thread is currently scheduled on. Every thread should show a value within your pinned range. If any land outside it, the isolcpus parameter was not applied — run cat /proc/cmdline to confirm it appears in the active boot parameters.

For a latency measurement inside a Linux guest, install and run cyclictest from the rt-tests package:

apt install rt-tests -y
cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 --loops=10000

On a pinned, isolated 4-core setup with nohz_full on a 13th-gen Intel host, worst-case latency consistently lands under 80 µs. Without pinning on the same hardware under moderate host load, worst-case values hit 3-8 ms. That is a 40x difference at the p99.99 — the exact improvement that eliminates audio dropouts in a DAW or micro-stutters in a GPU passthrough gaming VM.

When CPU Pinning Is Worth the Effort (and When It Isn't)

Worth pinning:

• GPU passthrough gaming VMs: frame time consistency depends on stable vCPU scheduling; even 2 ms jitter shows up as stutters at 144 Hz
• Audio production workstations: real-time audio at 48 kHz with a 128-sample buffer needs scheduling latency well under 3 ms
• Low-latency databases: Postgres, Redis, or ClickHouse under sustained query load benefit measurably from cache-warm cores
• Home Assistant with heavy integrations: fast polling loops on a loaded host miss intervals without dedicated cores

Not worth pinning:

• General-purpose web servers: CFS handles bursty traffic better than static affinity; pinning forfeits burst headroom
• LXC containers: use cpulimit cgroup throttling instead — the overhead-to-benefit ratio for LXC pinning is rarely justified
• Lightly loaded single-VM hosts: CFS already gives a near-idle VM the run of all available cores
• Batch compute VMs: a VM that runs a 30-second ffmpeg transcode every few hours will not notice pinning

The gotcha I ran into: pinning a VM to cores 0-3 on a system where the Proxmox host was using core 0 for NVMe interrupt handling caused more latency variance than no pinning at all. Always check cat /proc/irq/*/smp_affinity_list after setting up pinning, and move storage and network IRQs off your isolated cores with echo <cpu-mask> > /proc/irq/<n>/smp_affinity.

Conclusion

CPU pinning on Proxmox VE 9 is a 20-minute configuration change with immediate, measurable results for latency-sensitive workloads: isolcpus in GRUB, cpuaffinity in the VM config, and a taskset check to confirm. The logical next step is interrupt affinity — disable irqbalance and manually assign NVMe and PCIe interrupts to your reserved host cores, or run irqbalance with a --banirq list for your storage and network devices. That is where the last few microseconds of jitter typically hide on a well-tuned Proxmox host.