VMware ESXi and vSphere Cluster Management

Monitor CPU Utilization and CPU Ready Time in VMware vSphere

Learn how to use vCenter Server performance charts to monitor ESXi and VM CPU utilization, investigate CPU Ready time, and diagnose CPU scheduling contention.

Why CPU utilization monitoring matters

CPU utilization is the proportion of available CPU processing capacity actively used during a measurement period. Monitoring it helps you understand demand on an ESXi host and on individual virtual machines.

A short-lived increase can be normal. For example, a report-generation job or application startup may briefly consume substantial CPU and then return to a lower level. Sustained high utilization, especially when it coincides with application slowness, is more likely to indicate resource pressure.

High CPU usage alone does not prove that a virtual machine is CPU constrained. A virtual machine can show high CPU usage while receiving CPU execution promptly. To determine whether workloads are waiting for access to a processor, examine CPU Ready time and correlate it with workload symptoms.

CPU constraints in virtual machines

A CPU-constrained virtual machine cannot obtain physical CPU execution time when it needs it. Its vCPU is ready to run, but the ESXi scheduler cannot immediately place it on an available logical processor.

This delay can reduce application responsiveness, increase transaction times, and make the guest operating system appear slow. CPU contention can affect one virtual machine or many workloads on the same host.

Constraints may originate from the ESXi host, such as CPU overcommitment or sustained host saturation. They can also result from virtual machine configuration, including oversized vCPU assignments, restrictive CPU limits, low CPU shares, reservations, affinity rules, or other scheduling constraints.

Important CPU and vSphere terms

  • vCPU: A virtual CPU assigned to a virtual machine.
  • Logical processor: A schedulable processing thread presented to ESXi by physical CPU cores and, where enabled, simultaneous multithreading.
  • ESXi host: The VMware hypervisor server that runs virtual machines.
  • vCenter Server: The vSphere management platform used to manage inventory and view performance information.
  • CPU contention: Competition for CPU resources that prevents workloads from receiving execution time promptly.
  • CPU overcommitment: Assigning more aggregate virtual CPU capacity than a host can simultaneously provide as physical execution resources.
  • CPU shares: A relative priority setting used to distribute CPU resources among competing virtual machines or resource pools.
  • Performance counter: A collected metric representing a measurable aspect of host or virtual machine performance.

CPU Ready time

CPU Ready time is the time a virtual machine's vCPU is ready to execute but must wait for the ESXi scheduler to place it on a logical processor. It is therefore a key indicator of CPU scheduling contention.

Ready time should be interpreted with care. The meaning of a value depends on the workload, the number of vCPUs assigned to the virtual machine, the chart's sampling interval, the units displayed, and how long the condition continues.

Values reaching thousands of milliseconds over an observation interval can warrant investigation, particularly when they repeatedly occur during reported performance problems. There is no single universal threshold that definitively identifies a problem in every environment. A value that matters for a latency-sensitive workload may be less important for a batch workload.

Common causes of elevated CPU Ready time

  • Host CPU overcommitment or saturation: The host has more runnable demand than its logical processors can service promptly.
  • Too many active virtual machines: Many workloads compete for the same available logical processors.
  • Excessive vCPU allocation: A virtual machine has more vCPUs than its workload requires. Large virtual machines can be harder to schedule, especially when several vCPUs must be scheduled together for a workload.
  • Insufficient CPU shares: A virtual machine receives less relative priority than competing workloads in a resource pool or on the host.
  • Resource settings: CPU limits, reservations, affinity rules, resource-pool configuration, and other placement or scheduling constraints can affect access to CPU.
  • Workload concentration: A heavily used group of virtual machines may be placed on one host while other hosts have available capacity.

CPU metrics for initial vSphere performance analysis

MetricWhat It IndicatesHow to Interpret ItFollow-Up Check
CPU utilizationCurrent CPU demand and consumptionSustained high use indicates pressure, but does not by itself prove scheduling delayCheck CPU Ready time and workload symptoms
CPU Ready timeTime a vCPU was ready but waiting for a logical processorRepeated elevation supports a possible CPU contention diagnosisConfirm units, interval, duration, and affected workloads
CPU sharesRelative priority during CPU competitionLower shares can reduce access when contention existsCompare with peer virtual machines and resource-pool settings
vCPU countVirtual processing capacity assigned to a virtual machineMore vCPUs are not always better and can increase scheduling complexityCompare configured vCPUs with actual application demand
Host logical processor capacityProcessing resources available to all workloads on the hostLimited capacity combined with high runnable demand can produce contentionReview host CPU utilization, workload density, and placement

Use vCenter Server performance charts to display CPU Ready

vCenter Server provides performance monitoring views for ESXi hosts and virtual machines. The advanced performance chart lets you select a metric group, time range, chart type, object, and performance counter.

  1. Select the target ESXi host in the vCenter inventory.
  2. Open the Monitor area.
  3. Open Performance and choose the Advanced view.
  4. Open Chart Options, or the equivalent chart configuration control in your vSphere version.
  5. Select CPU as the metric group.
  6. Choose Real-time as the time range for immediate or current analysis.
  7. Choose Line Graph as the chart type.
  8. Select only the relevant ESXi host as the chart object.
  9. Select the Ready performance counter.
  10. Apply the selection and inspect the resulting chart.

A Real-time performance chart is a short-term view intended for current or recent activity analysis. Use a longer historical range when investigating a recurring problem that is not happening at the time of observation.

Reading the CPU Ready chart

Look for periods where Ready values rise consistently or produce repeated spikes. Then compare those periods with the time of application slowness, guest operating system delays, scheduled jobs, and other workload activity.

Always verify the chart's units and collection interval before judging the magnitude of a value. A displayed value may represent accumulated time over an interval rather than a simple instantaneous percentage. The interval and observation period affect how a spike should be understood.

Correlate CPU Ready with host CPU utilization and demand. High utilization with low or stable Ready can mean that workloads are using CPU effectively without significant scheduling delay. High utilization combined with repeatedly elevated Ready is stronger evidence that virtual machines are competing for CPU access.

Compare the affected virtual machine with other virtual machines on the same host, workloads on other hosts, and the same workload during a healthy period. These comparisons help distinguish a host-wide condition from a problem involving one virtual machine's configuration or priority.

Potential causes of elevated CPU Ready time

Possible CauseTypical EvidenceValidation MethodPossible Corrective Direction
Host CPU saturationSeveral virtual machines show Ready elevation while host demand is highCompare host CPU utilization, demand, and Ready across the same intervalBalance workloads or add capacity after confirming the cause
Excessive vCPU allocationA large virtual machine has more vCPUs than its workload needsReview vCPU configuration and guest or application CPU demandRight-size the virtual machine in a controlled change
Insufficient CPU sharesOne virtual machine waits more than peers during competitionCompare shares with peer workloads and resource-pool prioritiesAdjust relative priority when justified by business importance
Resource-pool or limit configurationReady elevation occurs despite available capacity elsewhere or follows a configured constraintReview limits, reservations, resource-pool membership, and placement rulesRemove or revise inappropriate constraints
Workload concentration on one hostOne host has repeated Ready elevation while comparable hosts have capacityCompare host placement, active workloads, and cluster distributionRebalance workloads or review placement decisions

Initial response to possible CPU contention

  1. Verify that CPU Ready elevation is persistent or repeatedly recurring, rather than a single harmless spike.
  2. Confirm that the elevated period coincides with application or guest operating system performance symptoms.
  3. Review ESXi host CPU utilization, demand, logical processor capacity, and competing workloads.
  4. Determine whether the issue affects one virtual machine, several virtual machines, or the whole host.
  5. Evaluate whether the affected virtual machine has more vCPUs than its workload requires.
  6. Review CPU shares, reservations, limits, resource-pool membership, affinity rules, and other relevant scheduling settings.
  7. Consider workload balancing or additional host CPU capacity only after the evidence identifies a capacity or placement problem.

Practical example: a slow virtual machine during peak demand

Suppose users report that an application becomes slow between 10:00 and 11:00. Begin by confirming that time window and identifying the ESXi host running the virtual machine.

  1. Open the host's performance charts in vCenter Server.
  2. Configure an advanced CPU chart with Real-time data and the Ready counter, or use a suitable historical interval if the problem has already ended.
  3. Check whether Ready rises during the reported slowdown.
  4. Compare the pattern with host CPU utilization and other active workloads.
  5. Review the affected virtual machine's vCPU count and CPU-share configuration.

A high Ready pattern aligned with application slowness suggests CPU scheduling contention more strongly than CPU usage alone.

Practical example: high CPU use versus scheduling delay

Compare two environments. In the first, host CPU utilization is high but CPU Ready remains low and stable. In the second, host utilization is high and Ready is repeatedly elevated while users report delays.

The first environment may be handling a CPU-intensive workload effectively. The second provides evidence of scheduling delay and should be investigated for host saturation, excessive vCPU allocation, share imbalance, or other constraints.

Practical example: evaluating CPU shares

  1. Identify a virtual machine with elevated Ready during periods of competition.
  2. Review its CPU shares relative to peer workloads and its resource pool.
  3. Determine whether its configured priority matches its business importance.
  4. Make any change in a controlled manner and recheck performance during comparable contention.

CPU shares influence relative access to CPU resources when contention exists. They do not create additional physical CPU capacity.

Troubleshooting guide

A virtual machine is slow and CPU utilization is consistently high

  1. Check CPU Ready time for the relevant period.
  2. Check ESXi host CPU demand and utilization.
  3. Determine whether the problem affects one virtual machine or several workloads.
  4. Review vCPU sizing and CPU resource settings.

Persistent Ready elevation supports a CPU scheduling-contention diagnosis. High utilization alone does not.

CPU Ready values are elevated on an ESXi host

  1. Confirm the chart interval and units.
  2. Identify whether the condition is sustained or occasional.
  3. Review host workload density and virtual machine activity.
  4. Check for oversized virtual machines and unequal share allocations.
  5. Examine limits, reservations, resource pools, affinity rules, and restrictive placement settings.

The result may indicate host overload, allocation imbalance, or scheduling constraints. Correlate the chart with configuration and workload behavior before changing resources.

A virtual machine has high CPU usage but CPU Ready remains low

  1. Investigate application demand inside the guest.
  2. Assess whether the virtual machine is legitimately CPU intensive.
  3. Review guest operating system and application-level CPU consumers.

In this case, the virtual machine may be consuming CPU effectively rather than waiting for ESXi scheduling.

Exam-relevant notes

  • CPU utilization is a demand and consumption indicator; it is not conclusive proof of CPU contention.
  • CPU Ready measures time that a ready vCPU waits for scheduling on a logical processor.
  • Interpret Ready values using the displayed units, sampling interval, vCPU count, workload behavior, and observation duration.
  • CPU shares provide relative priority during contention; they do not add CPU capacity.
  • Right-sizing vCPUs can improve scheduling efficiency when a virtual machine is oversized.
  • Always correlate performance counters with symptoms and competing workloads before concluding that CPU is the root cause.

Summary

Use CPU utilization to understand demand on ESXi hosts and virtual machines, but use CPU Ready time to investigate whether vCPUs are waiting for execution. In vCenter Server, select the host, open Monitor, Performance, and Advanced charts, choose CPU and Real-time data, use a line graph, select the host object, and display the Ready counter.

Persistent or repeated Ready elevation that aligns with user-visible performance problems justifies further review of host saturation, workload placement, vCPU sizing, CPU shares, resource pools, limits, reservations, and affinity rules. Make capacity or configuration changes only after correlating the chart with the actual workload and environment.

For a focused reference to this lesson, see Monitor CPU Utilization.