How should I allocate vCPUs and NUMA resources to virtual machines?
A vCPU is a schedulable virtual processor, not a guarantee of an exclusive physical core. Guest performance depends on host contention, memory locality and the application’s ability to use parallelism. Start with measured demand and host headroom; excessive vCPU allocation or rigid pinning can increase contention or worsen latency.
Before you start
- Host topology access and the exact libvirt guest identity.
Instructions
1. Inspect host CPU and memory topology
Check the host’s NUMA capacity before deciding whether a large guest fits within one locality domain or needs a deliberate multi-node layout.
numactl --hardware
lscpu -e=CPU,NODE,SOCKET,CORELogical CPUs can share a physical core. Compare node memory capacity and workload working set rather than counting threads alone.
2. Inspect the guest’s current CPU allocation
For a libvirt-managed VM, replace example-vm with the verified guest name and read its current vCPU information.
virsh --connect qemu:///system vcpuinfo example-vmReview vCPU count and any affinity information. Changing topology, pinning or memory placement requires a guest-specific plan and may need downtime.
3. Measure the result under representative demand
Compare application latency, throughput, host CPU contention and memory pressure before and after an approved adjustment. Preserve capacity for the host and other guests.
Check the result
- The guest meets its workload target without excessive host contention, and its CPU and memory placement are consistent with the physical topology.
Troubleshooting
- Adding vCPUs makes the application slower
- Check scheduling contention, application parallelism and cross-node memory access.
- One NUMA node is full while another is free
- Inspect binding rules and guest placement before applying broader affinity restrictions.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.