OneIQ collects a detailed set of CPU metrics for VMware hosts and virtual machines. These go beyond overall utilization: they describe both how much CPU was consumed and whether a virtual machine was able to obtain the CPU time it requested. This article explains each metric, the equivalent vSphere counter, and how to interpret the values.
Where to Find CPU Metrics
CPU metrics are available in the OneIQ Portal and in the Entity Excel export.
In the OneIQ Portal, go to Entities, select a VMware Host or VMware Virtual Machine in the table, and click Metrics to open the Explore metrics panel.
The same values are included in the Entity Excel export.
How OneIQ Reports CPU Metrics
Units. In the Explore metrics panel, CPU metrics are grouped by unit: % (percentage), CU (Compute Units), and MHz (clock frequency). The same consumption therefore appears as CPU Used (%), CPU Used (clock frequency) (MHz), and Normalized CPU Used (CU).
Normalization. Percentage values are normalized per vCPU (virtual machine) or per core (host). For this reason, CPU Ready should be read per vCPU.
Rollup. Charts default to a 95th percentile rollup, so values reflect sustained behaviour rather than short spikes.
VMware CPU Metrics
Metric (OneIQ Portal label) | vSphere / esxtop counter | Unit | Description |
CPU Utilization |
| % | Overall CPU consumption. |
CPU Used |
| % | Physical CPU time charged to the VM or host. |
CPU Demand |
| MHz | CPU the entity requested over the interval. |
CPU Ready |
| % | Time ready to run but waiting for a physical core. Indicates scheduling contention. |
CPU Wait |
| % | Time not running because idle or blocked on a VMkernel resource such as I/O or swap. Excludes waiting for a core, which is CPU Ready. |
CPU Co-stop |
| % | Time a multi-vCPU VM's vCPUs were held to stay synchronized. |
CPU Latency |
| % | Time the entity could not run due to contention, limits, or power management. |
CPU Idle (host) |
| % | Portion of Wait where the CPU had no work. |
CPU Run (VM) |
| % | Time scheduled and running. |
CPU System (VM) |
| % | Time system services ran on behalf of the VM. |
CPU Overlap (VM) |
| % | Time interrupted to service other VMs. |
Also available: CPU Used (clock frequency) and CPU Capacity (clock frequency) in MHz; Normalized CPU Used in CU; and, on hosts, CPU Core Utilization and CPU pCPU Utilization (with their Hz and CU variants).
Host vs. virtual machine. The OneIQ Portal exposes a slightly different set for each. CPU Idle, CPU Core Utilization, and CPU pCPU Utilization appear on hosts. CPU Run, CPU System, and CPU Overlap appear on virtual machines. Virtual machines do not have a separate CPU Idle metric; idle time is included in CPU Wait.
Interpreting Key Metrics
CPU Utilization, CPU Used, and CPU Demand
CPU Utilization and CPU Used show how much CPU was consumed. CPU Demand shows how much the entity requested. Compare CPU Demand with CPU Used (clock frequency), as both are reported in MHz.
Used ≈ Demand: the VM is getting the CPU it needs.
Used < Demand: the VM is constrained, typically due to host CPU contention or scheduling delays.
Used > Demand: the VM is consuming more than it requested, usually from spikes or multi-vCPU activity.
As general guidance (per Broadcom's ESXi 8.0 rightsizing documentation), sustained CPU Utilization at or below 80% is normal, leaving headroom for spikes. Sustained values near 100% indicate undersizing. CPU Utilization can also exceed 100% on modern CPUs; see CPU Utilization is showing more than 100%.
CPU Ready
CPU Ready is the time a vCPU was ready to run but waiting for a physical core. It indicates CPU scheduling contention and often explains slow performance when utilization appears low. Read it per vCPU. Broadcom's ESXi 8.0 documentation provides the following thresholds:
CPU Ready (per vCPU) | Interpretation |
Below ~5% | Benign; generally no problem |
5% to 10% | Investigate |
Above 10% | Noticeable performance impact; address it |
Sustained high CPU Ready generally indicates host-level contention rather than undersizing of the individual VM. Common causes include too many vCPUs assigned to a VM, host CPU overcommitment, and multiple high-load VMs on the same host. To reduce it, right-size the vCPU count, rebalance workloads with vMotion or DRS, or add physical CPU capacity. Note that CPU reservations do not resolve CPU Ready, as they guarantee frequency rather than scheduling slots.
CPU Wait and CPU Idle
CPU Wait is the time a vCPU was not running because it was idle (no work) or blocked waiting on a VMkernel resource such as storage I/O or memory swap. It does not include time waiting for a physical core, which is measured separately by CPU Ready. Idle time is normally the largest component of CPU Wait, so a high value typically reflects a lightly loaded virtual machine rather than a problem; the non-idle portion, such as I/O or swap wait, is the more relevant figure. CPU Idle is reported separately for hosts; on virtual machines, idle time is included in CPU Wait.
Reading CPU Ready, CPU Wait, and CPU Co-stop together
When a virtual machine appears slow but CPU Utilization looks low, the combination of these three metrics (all in the Processor section) points to the cause:
CPU Ready (%RDY) | CPU Co-stop (%CSTP) | CPU Wait (%WAIT) | Diagnostic conclusion |
High (>5%) | Low (<3%) | Normal / low | Host-level oversubscription — the physical host cannot supply enough CPU cycles for the combined demand of all VMs. |
High (>5%) | High (>3%) | Normal / low | VM oversizing (too many vCPUs) — the ESXi scheduler cannot co-schedule all of the VM's vCPUs at once; reduce the vCPU count. |
Low | Low | High | Non-CPU bottleneck — the VM is idle or waiting on storage, memory, or network rather than CPU. |
CPU Co-stop
CPU Co-stop applies only to virtual machines with multiple vCPUs. It measures the time the VM's vCPUs were held to remain synchronized. Per Broadcom's ESXi 8.0 documentation, below approximately 3% per vCPU is normal. Sustained higher values indicate the VM has more vCPUs than it can use effectively, and reducing the vCPU count usually improves performance.
CPU Latency
CPU Latency is the overall percentage of time an entity could not run because of contention, CPU limits, or power management. It provides a single summary indicator of whether the entity was constrained.
The Three "Used" Views
Because the metrics are grouped by unit, CPU consumption is shown three ways for the same entity:
CPU Utilization / CPU Used (%): consumption relative to the entity's own capacity.
CPU Used (clock frequency) (MHz): raw clock consumed; compare with CPU Capacity (clock frequency).
Normalized CPU Used (CU): consumption expressed in Compute Units, allowing comparison across different CPU models. See What is a Compute Unit (CU) in OneIQ.
Comparing OneIQ with VMware vSphere/vCenter
The CPU values in OneIQ exports and reporting are 95th percentile values, not averages. They represent the level below which 95% of observed data points fall, which filters out short-term spikes and reflects sustained demand. When comparing against vSphere or vCenter, which can show raw performance counters including spikes, it is normal for OneIQ to read lower during spikes even when the longer-term trend is similar.
VMware vSphere/vCenter and OneIQ also present the same CPU scheduling data in different ways. VMware shows the raw values collected from the virtual machine, while OneIQ converts them into percentage-based metrics and normalizes them across the VM's virtual CPUs. As a result, OneIQ's numbers tend to appear lower and will not match VMware vSphere/vCenter directly, even though both represent the same underlying activity.
Separately, vSphere and vCenter can legitimately show CPU usage above 100%, because usage is calculated against a baseline clock speed and modern CPUs can run above that baseline (for example, with turbo boost). vSphere 8.x no longer caps these values at 100%. See CPU Utilization is showing more than 100%.
Other Platforms
The full set of scheduler-state metrics (Ready, Wait, Co-stop, Run, System, Overlap) is specific to VMware. Other platforms expose a smaller set. For example, Nutanix also provides CPU Ready for virtual machines, while cloud platforms (AWS, Azure, GCP) and Kubernetes generally report CPU Utilization only, with Kubernetes also reporting used cores.
Key Takeaway
CPU Utilization shows how busy a VM or host is. Comparing CPU Wait alongside CPU Ready and CPU Co-stop can help isolate the root cause of CPU performance degradation (read CPU Ready and CPU Co-stop per vCPU).
Examining these three metrics along with CPU Utilization lets you differentiate between a VM that is waiting on the host (contention), waiting on itself (co-stop), or waiting on external resources (storage or memory).
Related articles: CPU Utilization is showing more than 100% · What is a Compute Unit (CU) in OneIQ · Understanding Storage Metrics in OneIQ
External references: Broadcom — Rightsizing virtual machines on ESXi 8.0 (KB 438023); ESXi host CPU usage alarms and VM performance degradation due to vCPU overprovisioning (KB 421543); Understanding the CPU ready values in the vSphere Client advanced performance charts (KB 387750).