Fix High VM CPU Ready Time on VMware vSphere 7/8

When This Error Happens

You're checking your vSphere 7 or 8 environment and you see a warning: "VM CPU Ready Time Threshold Exceeded." This usually shows up in vSphere performance charts or in monitoring tools like vRealize or SolarWinds. The trigger is simple: your host has too many virtual CPUs asking for time on too few physical CPU cores. I've seen this most often on hosts running 10-15 VMs, each with 4 or 8 vCPUs, on a box with only 12 physical cores. The host can't keep up.

You'll notice your VM feels slow. Applications inside the VM lag. The guest OS shows low CPU usage (like 10-20%), but the VM still feels sluggish. That's the telltale sign: low CPU inside the VM but high CPU ready time outside. The VM is waiting for its turn on a physical core.

What's Actually Happening

CPU ready time is the percentage of time your VM is ready to run but the hypervisor hasn't given it a physical CPU yet. VMware measures this in milliseconds. A healthy VM has CPU ready time below 5%. Above 10% means the VM is waiting more than it's working. Above 20% and your users will complain.

Think of it like a checkout line. Your VM has a cart full of work. It steps up to the register (the physical CPU), but there's a line. The time spent waiting in line is CPU ready time. If you have too many checkout lines (vCPUs) for the number of cashiers (physical cores), the wait gets long. That's exactly what happens here.

The root cause is almost always one of two things: (1) you gave a single VM too many virtual CPUs (like 16 vCPUs on a host with 20 cores), or (2) you stuffed too many VMs onto one host. The host can't schedule all the vCPUs fast enough. The VMware CPU scheduler is good, but it can't break physics.

The Fix

Here's how to fix it. I'll give you three approaches. Try them in order. The first fix works 80% of the time.

Step 1: Check Which VM Is the Problem

1. Open the vSphere Client (web UI).
2. Select the host or cluster that has the alert.
3. Go to the Monitor tab, then click Performance.
4. Change the chart to Advanced view.
5. Add the counter CPU Ready (it's under CPU category).
6. Look at the VMs with the highest CPU ready time. Those are the ones causing the problem.

After this, you'll see which VMs are waiting the most. Write down their names and current vCPU count. I've seen cases where a single VM with 16 vCPUs had 40% ready time, while every other VM was fine.

Step 2: Reduce vCPU Count on the Affected VM

This is the fix. Most applications don't need 8 or 16 vCPUs. A web server or database VM might run just as well on 4 vCPUs. The OS inside uses only what it needs anyway. With fewer vCPUs, the scheduler can give each one more time on the physical core.

1. Right-click the VM and select Edit Settings.
2. Under Virtual Hardware, find CPU.
3. Reduce the number of CPUs. For a VM with 8 vCPUs, try 4. For 16, try 8 or even 4. If you're not sure, check the guest's performance. If the OS shows CPU usage below 50% consistently, you can drop the vCPU count by half.
4. Click OK.

After clicking OK, the VM will restart? No, it doesn't. VMware allows hot changes to vCPU count if the guest OS supports it (Windows Server 2012+ and most Linux distros do). But to be safe, plan a reboot during maintenance. After the change, check the CPU ready time again. It should drop below 5% within minutes.

Step 3: Balance the Hosts (If Reducing vCPUs Isn't Enough)

If the ready time is still high across multiple VMs, the host itself is overloaded. You have too many VMs on one physical machine. Use vMotion to move some VMs to a less busy host.

1. Right-click the VM and select Migrate.
2. Choose Change host.
3. Pick a host with low CPU usage (below 70% is a good target).
4. Click Finish.

After the migration, the CPU ready time for the moved VM should drop immediately. Check the original host's performance too. If the ready time stays high on the original host, you'll need to move more VMs.

What to Check If It Still Fails

You reduced vCPUs and moved VMs. The ready time is still above 10%. Now what? Check these things:

• Check for resource pools with shares set too low. If the VM is in a resource pool with low CPU shares, it will always wait. Go to the VM's Edit Settings > Resources > CPU and verify the shares are Normal (1000) or higher.
• Check for DRS misconfiguration. If DRS is set to manual or partially automated, it won't move VMs automatically. Set DRS to fully automated to let vSphere balance the load. In the cluster's settings, under vSphere DRS, set the automation level to Fully Automated with a migration threshold of 3 (moderate).
• Check the physical CPU model. Older CPUs like Intel Xeon E5-2600 v3 have fewer cores and slower speeds. If your host has these, you might need to upgrade hardware. There's no software fix for underpowered CPUs.
• Check for hyper-threading being disabled. In the host's BIOS, hyper-threading doubles the logical cores, which helps the scheduler. If it's off, the host has half the logical CPUs. Enable it in the BIOS. This is a host reboot, so plan downtime.

One more thing: if you run a single VM that needs lots of CPU (like a database server for 500 users), sometimes you can't fix it with software. You'll need to split the workload across two VMs or move that VM to a host with more physical cores. I've had to do that twice in my career. It's rare, but it happens.