Dennis HilkLinux Fix LabDE

Performance & Virtualization

A guest loses CPU time to host contention or quotas

A guest feels CPU-starved despite unused virtual CPUs. Compare guest steal time with host placement and quotas before adding more vCPUs.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

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 5

Interpret 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-vm

Interpret 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-vm

Interpret 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?

Share this solution#

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?

Share this solution#

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.