VMware ESXi and vSphere Cluster Management
Monitor CPU Utilization and CPU Ready Time in VMware ESXi
Learn how to use vCenter Server performance charts to investigate ESXi CPU utilization, CPU ready time, scheduling contention, and virtual machine slowness.
Why Monitor CPU Utilization in ESXi?
CPU utilization is the processor capacity consumed over time by an ESXi host or a virtual machine workload. Monitoring it at both levels helps distinguish normal workload activity from CPU contention, which occurs when runnable virtual machines compete for processor resources and execution is delayed.
A host can have sustained CPU demand because its workloads are genuinely busy. A virtual machine can also appear slow even when its guest operating system does not report constant maximum CPU usage. The guest may be ready to run but waiting for ESXi to schedule its vCPUs. For this reason, high CPU usage alone does not prove that CPU is the performance bottleneck. Review utilization, scheduling delay, workload behavior, and user-visible symptoms together.
At the ESXi host level, monitoring reveals whether many workloads are competing for limited capacity. At the virtual machine level, it helps identify which workload is waiting, consuming CPU, or configured with more virtual CPUs than it can use efficiently.
How ESXi Schedules Virtual CPUs
An ESXi host is the VMware hypervisor system that provides compute resources and schedules virtual machines. Each virtual machine receives one or more vCPUs, which are virtual processor units presented to the guest operating system.
ESXi schedules vCPUs onto available logical processors. A logical processor is an execution context visible to ESXi, such as a physical processor core or a hardware-threaded core. Physical CPU capacity and logical processor capacity are not unlimited: active vCPUs from multiple virtual machines compete for the processor resources available on the host.
When a runnable vCPU cannot immediately be scheduled, it waits. The wait can result from constrained host capacity, concurrent workload spikes, scheduling priorities, or resource settings such as CPU shares and limits. This scheduling delay is different from a guest simply having no work to do.
What Is CPU Ready Time?
CPU ready time is the accumulated time during which a runnable virtual machine or vCPU is prepared to execute but is waiting for ESXi to schedule it on a logical processor. It is a key indicator of CPU contention because it measures waiting caused by processor scheduling rather than CPU work performed by the guest.
In vCenter performance charts, the Ready counter is commonly displayed as accumulated time in milliseconds for the chart sampling interval. Interpretation depends on the collection interval, the number of vCPUs, the workload pattern, and whether the metric is viewed for a host or a virtual machine. Do not treat a raw millisecond value as a universal threshold without considering that context.
Persistently large ready-time values can indicate an oversubscribed host, excessive vCPU allocation, insufficient CPU entitlement, or competing workloads that create demand spikes. A short isolated spike may be normal during a brief burst and should be correlated with utilization and application symptoms before corrective action is taken.
View CPU Ready in vCenter Server
Use the following workflow for an immediate investigation of a specific ESXi host. Names and placement of controls can vary slightly between vSphere versions, but the required concepts are the same.
- Select the target ESXi host in the vCenter inventory.
- Open Monitor, then open Performance.
- Open the advanced performance-chart view, or use the chart options or chart configuration interface.
- Set the metric group to CPU.
- Set the time range to Real-time for a current or recent investigation.
- Choose a Line Graph presentation.
- Limit the chart object selection to the ESXi host being investigated.
- Select the Ready performance counter.
- Apply the configuration and inspect the resulting chart.
A real-time performance chart is useful when users are reporting slowness now or when you are reproducing a problem. For recurring issues outside the real-time window, use an appropriate historical performance interval and compare the same periods across hosts and virtual machines.
Interpreting the CPU Ready Chart
Look for repeated or sustained elevation rather than relying on one short spike. First identify the investigation period, then correlate ready time with host CPU utilization, virtual machine demand, and the time users observed slowness.
- Short spike: May represent a transient workload burst. Check whether it coincides with a brief demand increase or a scheduled task.
- Repeated elevation: Suggests a recurring scheduling problem, especially if it appears during predictable busy periods.
- Sustained elevation: Requires investigation of host capacity, competing workloads, vCPU sizing, and resource allocation.
- High host utilization with high ready time: Strengthens the case for host CPU contention, but confirm which workloads are responsible.
- High ready time on one VM: Compare that VM's vCPU count, demand, shares, limits, and resource-pool settings with peer workloads.
Values in the thousands of milliseconds over a chart interval can be a warning sign, but they are not a universal pass-or-fail threshold. A value must be interpreted with its sampling interval, vCPU count, chart level, workload pattern, and user impact.
| Signal | What it measures | Possible interpretation | Recommended follow-up |
|---|---|---|---|
| Host CPU utilization | Processor capacity consumed across the ESXi host | The host may be busy, although high usage alone does not prove contention | Correlate with Ready, active VMs, demand, and application symptoms |
| CPU ready time | Time a runnable VM or vCPU waits for scheduling | Potential CPU contention or insufficient entitlement | Check duration, interval, host load, vCPU sizing, and resource settings |
| VM CPU demand or usage | CPU the virtual machine wants or consumes | Shows workload behavior and whether the guest is actively requesting CPU | Compare demand with usage and ready time during the same period |
| Configured vCPU count | Number of virtual CPUs assigned to the VM | An oversized VM may create unnecessary scheduling competition | Right-size vCPUs according to workload requirements and observed demand |
| CPU shares or resource-pool entitlement | Relative priority or allocation during contention | A low-share VM may receive CPU less readily when resources are constrained | Review shares, limits, reservations, and parent resource-pool settings |
Common Causes of Elevated CPU Ready
Host CPU Oversubscription
Oversubscription occurs when the active virtual CPU demand exceeds what the host can schedule promptly. Too many active vCPUs may compete for the available logical processors, particularly during simultaneous workload peaks.
Oversized Virtual Machines
A VM configured with more vCPUs than its workload can efficiently use may contribute to scheduling pressure. More vCPUs do not automatically make an application faster. Review actual demand, application parallelism, and guest performance before adding or removing vCPUs.
CPU Shares and Resource Pools
CPU shares are relative entitlement settings used to prioritize workloads competing for constrained CPU resources. A resource pool is a vSphere grouping that can control CPU and memory reservations, limits, and shares for its contained workloads.
Shares matter primarily during contention. Increasing shares does not create additional physical CPU capacity, and it should not be used as the first response to every ready-time alert. Review the VM's shares and any parent resource-pool settings, and compare them with the business priority of competing workloads.
Concurrent Demand Spikes
Backups, reporting, antivirus scans, batch processing, and other scheduled work can create short or recurring CPU peaks. Compare the ready-time chart with the activity of other VMs on the same host to identify shared timing.
CPU Ready Investigation Checklist
| Observation | Potential cause | How to validate | Possible action |
|---|---|---|---|
| Repeatedly high ready time | Persistent host contention, oversized vCPU allocation, or insufficient entitlement | Review multiple intervals, host demand, VM activity, vCPU counts, and resource settings | Right-size VMs, rebalance workloads, or expand host capacity |
| High ready time during host CPU peaks | Concurrent workloads are consuming available processor capacity | Compare Ready with host utilization and the activity of other VMs | Schedule or redistribute work, migrate workloads, or add capacity |
| High ready time on a large-vCPU VM | The VM may be overprovisioned relative to its workload | Compare configured vCPUs with demand, application behavior, and peer VMs | Consider careful vCPU right-sizing and retest performance |
| High ready time for a low-share workload | Lower relative entitlement inside a constrained host or resource pool | Compare shares, limits, reservations, and parent pool settings | Align allocation with workload priority after confirming the requirement |
| Short isolated ready-time spike | Transient demand burst or scheduling event | Check duration, recurrence, user impact, and concurrent activity | Monitor and correlate before changing configuration |
Practical Investigation: A Slow VM During Peak Hours
- Open the affected ESXi host in the vCenter inventory.
- Open its advanced performance chart settings.
- Configure a real-time CPU line graph using the Ready counter.
- Check whether ready time rises during the same period users report slowness.
- Compare the timing with host CPU utilization and other active workloads.
- Review the VM's vCPU count, CPU shares, limits, reservations, and resource-pool placement.
The expected finding may be a VM that is CPU-constrained even though the guest operating system does not show continuous maximum CPU usage. The guest can be waiting outside the guest's normal CPU usage measurement while ESXi determines when it can run.
Troubleshooting Examples
The VM Is Slow but Guest CPU Is Not Always at Maximum
Check Ready on the associated host during the reported slow period. Determine whether the VM is waiting to be scheduled, then review host CPU load and contention from other VMs. Check vCPU sizing and CPU shares before changing the guest operating system or application.
A likely resolution is to reduce contention through VM right-sizing, workload redistribution, or additional host CPU capacity, depending on the evidence.
Ready Time Stays Elevated Across Several Intervals
Confirm that the pattern is sustained rather than a one-time event. Check for a highly utilized host, concurrent demand, oversized VM configurations, and resource-pool or share settings. Rebalance workloads, reduce unnecessary vCPU allocations, and correct CPU resource allocation settings where appropriate.
One Workload Has Poor Responsiveness While Peers Are Acceptable
Compare the affected VM's settings with peer workloads. Check whether it has lower CPU shares in a constrained resource pool, or whether a restrictive CPU limit is preventing it from using available capacity. Align shares, limits, and reservations with workload priority and capacity requirements.
Corrective Actions
- Right-size virtual machines: Remove unnecessary vCPUs when workload evidence supports doing so.
- Balance workloads: Move or migrate workloads so CPU demand is distributed across suitable hosts.
- Review resource allocation: Validate shares, reservations, limits, and resource-pool hierarchy against business priorities.
- Expand capacity: Add host CPU capacity or hosts when sustained demand exceeds the cluster's practical capacity.
- Investigate scheduling patterns: Identify recurring backup, batch, or reporting activity that coincides with contention.
Do not increase shares indiscriminately or add vCPUs solely because a VM is slow. Use the Ready chart together with host utilization, VM demand, configuration, and application symptoms to select the least disruptive correction.
Summary
CPU utilization monitoring shows how much processor capacity is being consumed, while CPU ready time shows when runnable virtual machines are waiting for ESXi scheduling. Sustained ready-time elevation, especially when correlated with high host demand and user-visible slowness, is a strong reason to investigate CPU contention.
Start with the affected host in vCenter, open Monitor > Performance, configure the advanced real-time CPU line chart, select the host and the Ready counter, and then correlate the result with competing workloads and VM resource settings. Remediation may involve right-sizing, workload balancing, resource-allocation changes, or additional capacity.
For foundational vSphere administration, review the VMware ESXi online course. You may also need guidance on adding an ESXi host to the vCenter Server inventory or on alarms in vSphere.