VM CPU Ready Time High – Fix for VMware Admins

Your VM is Crawling? CPU Ready Time is the Culprit

I've been there – you get a call from a user saying their VM is slower than a dial-up modem. You check the metrics, and there it is: CPU ready time pegged at 15% or higher. Frustrating, right? Let's cut the chatter and get this fixed.

The Quick Fix: Reduce vCPUs or Move the VM

First step – check if your VM has too many virtual CPUs. Saw a client last month with a SQL server that had 8 vCPUs. But their DB only used 2 cores at peak. That VM had 20% CPU ready because the hypervisor fought to schedule all 8 threads. I dropped it to 4 vCPUs, and ready time fell to 2% overnight.

Here's the rule: If CPU ready is above 5%, you're oversubscribed. Do this:

1. Log into vCenter.
2. Find the VM. Go to Monitor > Performance > Advanced.
3. Look at CPU Ready metric. If it's over 5% for more than 10 minutes, act.
4. Reduce vCPUs. Don't give a VM 16 cores if it only uses 4. Right-click the VM, Edit Settings, reduce CPU count.
5. If you can't reduce (legacy app requirement, I know), vMotion the VM to a less crowded host.

Had a case where a web server VM had 6 vCPUs. User swore they needed them. I showed them the CPU usage graph – never above 10% on any core. Dropped to 2 vCPUs. Ready time went from 12% to 1%. User was happy.

Why This Works

CPU ready time is when a VM wants CPU but the hypervisor can't give it – because the host's physical cores are busy. Think of it like a restaurant kitchen. Too many chefs (vCPUs) but only 2 stoves (physical cores). They wait. That's ready time.

By reducing vCPUs, you match the VM's actual demand. The hypervisor has less to schedule. Less contention, less waiting. If you move to a less busy host, you give the VM more breathing room on physical cores.

Technical note: CPU ready is measured in milliseconds. A rule of thumb – sum of all VM vCPUs on a host shouldn't exceed physical cores by more than 4:1 for production workloads. I've seen 8:1 ratios cause ready time over 30%. That's a big no-no.

Less Common Variations of the Same Issue

Not every high CPU ready case is about too many vCPUs. Here's what else I've hit:

1. CPU Co-Stop (ESXi Bugs or NUMA Issues)

Sometimes you see CPU ready spike but vCPU count is fine. I had a VM on ESXi 6.5 that showed 30% ready. Turns out the VM had 4 vCPUs and the host had two NUMA nodes of 8 cores each. The VM's memory spanned both nodes. ESXi got confused and introduced co-stop delays. Fix: set numa.nodeAffinity in the VM's advanced settings to pin it to one NUMA node. Ready time dropped to 3%.

2. CPU Overcommit on Nested Virtualization

Running ESXi inside a VM? I've seen that. The nested hypervisor creates its own vCPU schedule on top of the host schedule. That doubles ready time risk. Best fix: don't nest ESXi for prod. But if you must, set the outer VM's CPU reservation to match its vCPUs.

3. Hyper-Threading Confusion

Saw a weird one: a VM with 2 vCPUs on a host where HT was enabled. The host had 8 physical cores and 16 logical. The VM's ready time hit 10% because ESXi scheduled both vCPUs on the same physical core's threads. Fix: enable CPU affinity to spread vCPUs across different physical cores. Or disable HT on that host for critical VMs.

4. Storage or Memory Pressure Masquerading as CPU Ready

This trips people up. High CPU ready can look like the metric but it's actually storage latency. A VM waiting for disk reads has CPU idle but your tool shows ready? No. Check ESXTOP. If %RDY is high and %MLMTD is also high, you might have memory ballooning. Real story: client thought it was CPU ready, but the VM had 512MB memory and ran a database. Added 2GB RAM, ready time vanished.

Prevention – Keep It Out of the Future

Stop waiting for calls. Here's how to avoid high CPU ready:

• Monitor proactively. Set vCenter alerts for CPU ready over 5%. I configure mine to email me when any VM hits 10% for 5 minutes. Takes 10 minutes to set up, saves you hours.
• Right-size VMs from day one. Don't give 8 vCPUs to a lightweight app. Use a baseline: check peak CPU usage over a week. Give 2x the average, not 10x.
• Keep host ratio in check. For production, don't exceed a 4:1 vCPU-to-physical-core ratio. For high-performance VMs, keep it at 2:1 or less.
• Use CPU reservations sparingly. Only for critical VMs. Reservations reduce flexibility and can actually cause ready time on other VMs on the same host.
• Plan your maintenance windows. When you add a big VM, check the host's current CPU ready. If it's already at 4%, adding another big VM might push it over 10%. vMotion one or two small VMs off first.

Had a client who never checked CPU ready. Their VDI farm had 500 desktops on 4 hosts. Ready time was 25% average. Users complained daily. We reduced vCPUs per desktop from 4 to 2, added a host, and set alerts. Calls stopped.

Bottom line: high CPU ready isn't a mystery. It's either too many vCPUs, a crowded host, or something weird like co-stop. Check the numbers, trust the math, and don't be afraid to shrink VMs. Your users will thank you.