Diagnose KVM performance by correlating host pressure with guest symptoms over the same time interval. Adding vCPUs or RAM without evidence can increase contention or hide the real storage/network bottleneck. Begin with read-only measurements.
IN THIS ARTICLE
Gather the details you will need
Record the affected guests, workload, latency/error target and recent changes. Identify scheduled backups, migrations and host maintenance. Collect baseline measurements without running destructive or saturation benchmarks against production storage.
01 Diagnose CPU, memory and disk contention on a KVM host
- Check host CPU use, run queue and pressure-stall information. Compare guest scheduling delay with physical saturation before deciding that the application needs additional vCPUs.
- Inspect available memory, swap activity, OOM events and pressure. Allocated guest memory is different from host memory that is actually available for concurrent demand.
- Measure storage latency, queueing and free capacity on the real backend. Look for backup traffic, snapshot growth, thin-pool metadata pressure or device errors affecting several guests at once.
- Check host and guest network counters, link speed and packet drops. A slow database call may be remote network latency rather than local CPU shortage.
- Correlate each observation with the affected application period, then make one justified change: reschedule competing work, reduce placement, repair storage/network faults or move workload to suitable capacity.
02 Example: compare guest allocation with host memory and I/O pressure
On the authorised KVM host, inspect the named VM and collect a short host sample during the incident. Replace VM_NAME with the guest in question. These commands do not change guest CPU, memory or storage allocation.
sudo virsh -c qemu:///system dominfo VM_NAME
free -h
vmstat 1 5Read the result: dominfo shows the guest's configured state and allocation, while the other commands describe the host. Compare the incident with host runnable tasks, available memory and I/O wait. A guest reaching its own limit can occur even when the host has spare resources, and host contention can affect several guests together.
Use monitoring over time and inspect the relevant storage path before reallocating resources. Do not infer a noisy neighbour from one short sample. Preserve the timestamp and compare guest-level application metrics so the remedy addresses the layer actually limiting performance.
Will assigning more vCPUs always make a guest faster?
No. Application parallelism, host scheduling and physical capacity determine the benefit. More virtual CPUs can add contention, so measure the workload and adjust within a tested capacity plan.
Confirm the expected result
Repeat the same representative workload after the change and compare latency, errors and resource pressure. Observe a normal peak and backup cycle. Confirm improvement in the guest service itself, not just a lower host average.
If the problem continues
If only one guest is affected while host resources are healthy, inspect its process, filesystem and application logs. If all guests pause together, prioritize shared host/storage infrastructure. Avoid disabling safety features, dropping caches repeatedly or killing unfamiliar QEMU processes to lower a graph. Preserve evidence of intermittent stalls before they disappear.