Symptoms & scope
- Guest response time worsens while the host runs other busy workloads.
- Guest steal time rises or vCPU pinning concentrates work on a small host CPU set.
Relevant environment
Linux guests under QEMU/libvirt; reported steal time depends on hypervisor support and is not every source of scheduling delay.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- Overcommitted host CPUs or restrictive pinning may delay runnable virtual CPU threads.
- Per-vCPU or whole-domain quotas can cap aggregate time; adding vCPUs does not increase that budget automatically.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Run read-only sysstat sampling inside the Linux guest; requires installed mpstat.
mpstat -P ALL 1 5Interpret the result: %steal is involuntary vCPU wait while the hypervisor serves other work. High values support host scheduling contention, but zero does not exclude all hypervisor or quota delay.
Check 2
Run on the host and replace the domain name; omitting CPU and vCPU assignments makes this a read-only query.
virsh -c qemu:///system vcpupin example-vmInterpret the result: Compare allowed host CPUs per vCPU with real host load and topology. Several busy vCPUs pinned to one host CPU can contend despite a wide guest topology.
Check 3
Reads scheduler values with existing libvirt access; do not add --set or assignments.
virsh -c qemu:///system schedinfo example-vmInterpret the result: Finite vcpu_quota or global_quota can explain a service budget. Live and persistent XML may differ, so inspect the appropriate state before editing.
Evidence-guided next steps
Right-size guest and host CPU allocation
If host contention is measured, reduce competing concurrent jobs or right-size the guest's vCPU count to available host capacity. Remove accidental overconcentration in pinning while preserving intended isolation.
Precautions: More vCPUs can worsen contention and are not automatically more throughput. Preserve emulator and I/O thread placement when reviewing affinity.
Recovery / rollback: Restore recorded vCPU topology and pinning through the same live/persistent configuration scope; reboot only if required by the guest change.
Did this solution help you?
Correct the intended domain CPU budget
If an unintended finite quota is the constraint, adjust that domain's per-vCPU or global budget through libvirt using measured host headroom. If the budget is deliberate, reduce guest concurrency to fit it.
Precautions: Changing global and per-vCPU quotas has different effects. A larger domain budget can degrade neighboring guests.
Recovery / rollback: Restore saved quota/period values and guest concurrency, then compare the same guest workload and host load.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- libvirt — CPU tuning, pinning and bandwidth (project or distribution documentation)
- libvirt — virsh scheduler and pinning queries (project or distribution documentation)
- mpstat — sysstat steal-time interpretation (project or distribution documentation)
Related hardware and driver context
These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.
Identify hardware locally