Low guest utilization does not rule out a scheduling problem
A virtual machine can be slow because a virtual CPU waits to run on the host, even when the guest's CPU chart looks unremarkable. CPU ready describes a scheduling state. It is different from the time the guest actually receives a processor and different again from application time spent waiting for storage or a remote service.
This guide investigates one VM's scheduling delay. It does not prescribe a universal CPU-ready threshold or recommend adding vCPUs to every slow VM. Begin with a business symptom, such as delayed requests during a shared-host batch window, and a timeline that can be compared with host evidence.
Setup: make the measurement comparable
Record the VM's vCPU count, host placement, resource settings and application symptom window. Identify the monitoring tool, sampling interval and whether the displayed value describes one virtual CPU or an aggregate. A summation collected over one interval cannot be compared directly with a percentage collected over another.
Use the supported vSphere performance view or an authorized esxtop session to inspect the affected VM and host. Preserve the original metric units. Collect guest CPU demand, application latency and storage or network waits alongside scheduling evidence. The extra context prevents a real database bottleneck from being misdiagnosed as host contention.
Illustrative incident: more vCPUs do not improve the queue
In this illustrative scenario, an application is given additional vCPUs after users report intermittent latency. The busiest period also contains several neighboring batch workloads. The VM's scheduling evidence worsens while useful application throughput does not improve.
The investigation compares the same workload before and after the sizing change. The team examines whether the application can use its assigned parallelism and whether the host can supply it during the busy window. This is a teaching example, not a measured client performance claim.
Troubleshooting: connect scheduling evidence with workload demand
| Observation | Evidence to compare | Working question |
|---|---|---|
| Ready time rises during a shared busy window | Host demand and neighboring workload schedule | Is physical capacity contested? |
| Guest demand is low but latency is high | Application waits and dependency timing | Is CPU scheduling actually on the critical path? |
| A larger VM performs no better | vCPU allocation, concurrency and scheduling metrics | Was the VM oversized for its workload? |
| Only one host placement shows the symptom | Comparable periods on each host | Does contention follow the host or the VM? |
Avoid interpreting the host-wide load average as a direct substitute for the VM's own scheduling evidence. Also distinguish ready time from co-stop and other runtime states. Use the definitions for the installed vSphere version and the selected monitoring tool.
Correct a measured constraint with a controlled experiment
Choose one reviewed change: adjust an unsuitable resource setting, right-size the VM, rebalance competing workloads or provide capacity. Define a comparable workload window before changing placement or sizing. Otherwise, a quieter business period can look like a successful infrastructure fix.
Do not remove reservations or limits globally, and do not assume that a CPU-count increase is reversible without guest or application planning. Record the previous settings, the owner-approved interruption window and the acceptance signal. A capacity change should improve the business path rather than merely change the color of one chart.
Verification, monitoring and SOP
Compare application latency, useful throughput and VM scheduling over equivalent demand periods. Check neighboring VMs so that moving the contention has not simply transferred the incident. Observe another representative busy window before treating the result as sustained.
Alert on scheduling symptoms together with application impact and capacity trends. An internal SLO can describe the accepted request-latency envelope under an agreed workload; it is not a vendor CPU-ready guarantee or contractual SLA. The SOP should record metric units, vCPU scope, sampling interval, host comparison, change owner and rollback settings.
See Clouvenix vmware virtualization for a reviewed implementation and operational handover.
Technical reference
Broadcom CPU-ready interpretation, Broadcom esxtop statistics. Reviewed 19 October 2026; use documentation for the installed product and release.