Hypervisor CPU Starvation Fix for VMware ESXi 7.0

You've got a VMware ESXi 7.0 host with five VMs. One VM—maybe a SQL server or a cryptominer—runs flat out at 100% CPU. The other four VMs start lagging. SSH sessions time out. Web apps crawl. You check vCenter and see CPU ready time spiking over 15% on the affected VMs. That's CPU starvation: the hypervisor can't give enough CPU time to every VM because one is eating it all.

Why This Happens

ESXi uses a scheduler to split CPU time between VMs. By default, all VMs get equal shares. But shares don't set a hard cap. One VM can use way more than its share if the others aren't asking for CPU. That's fine for bursty workloads. Bad when one VM is a CPU pig.

The real problem: ESXi has no default limit on CPU usage per VM. Shares only matter when there's contention. If you've got 8 cores and one VM uses 7, the other VMs fight over the last core. That's when ready time climbs. The scheduler can't force the busy VM to give up CPU until its time slice ends. So the other VMs wait.

You'll see this mostly on hosts with high consolidation ratios or mixed workloads—a web server VM next to a batch processing VM. Or if someone spun up a VM with too many vCPUs. More vCPUs than physical cores makes scheduling harder.

How to Fix It

The real fix is to set a CPU limit on the hungry VM or move it to a resource pool with a cap. Don't mess with shares unless you know what you're doing. Limits are blunt but work. Let's do this:

Step 1: Check CPU Ready Time

Open vCenter. Go to the host, then the Monitor tab, then Performance. Add a metric: CPU Ready. Normal is under 5%. If you see 10% or higher on the suffering VMs, you've got starvation. Also check the hungry VM's CPU usage—is it pegged at 100% for hours?

Step 2: Decide on a Limit

Pick a number. I'd cap the hungry VM at 50% of total host CPU. For a 16-core host, that's 8 cores. In MHz, that's 8 cores times your CPU speed. Let's say your cores run at 2.4 GHz. 8 x 2.4 GHz = 19.2 GHz = 19200 MHz. Round down to 18000 MHz to give some headroom.

Step 3: Set the CPU Limit

1. Right-click the hungry VM in vCenter. Select Edit Settings.
2. Go to Virtual Hardware, then CPU.
3. Find the Reservation, Limit, Shares section.
4. In the Limit field, type 18000 (or your calculated value).
5. Leave Reservation at 0 unless you need guaranteed CPU.
6. Click OK.
7. Wait 30 seconds. The change takes effect immediately.

After applying you should see the hungry VM's CPU usage drop to the limit. The other VMs' CPU ready time should fall below 5%.

Step 4: Verify the Fix

Go back to the Performance graph on the host. Refresh it. Look at CPU Ready for the VMs that were suffering. It should be back under 5%. Check the hungry VM—its CPU usage is capped but it's still running. If it's a critical app, you might need to raise the limit later. For now, balance is back.

What to Check If It Still Fails

If CPU ready time stays high, look at these:

• Too many vCPUs: The hungry VM might have 16 vCPUs on a 16-core host. That's maxed out. Reduce vCPUs to half the physical cores. Edit Settings, CPU, change Number of CPUs to 8. Reboot the VM.
• NUMA issues: ESXi tries to keep VM memory on the same CPU socket. If the VM has more vCPUs than cores per socket, cross-socket traffic adds latency. For a 2-socket host with 8 cores each, don't give a VM more than 8 vCPUs.
• Resource pool misconfiguration: If the hungry VM is in a pool with high shares relative to other pools, the scheduler gives it preference. Check pool settings. Set all pools to Normal shares unless you have a reason not to.
• Host overcommitment: If total vCPUs across all VMs exceeds physical cores by 4:1 or more, no limit will fix it. You need more hosts or fewer VMs. Move some VMs to another host using vMotion.
• Bad driver or guest OS: Rare but possible. If the VM runs an old OS or has virtio drivers from 2015, update them. VMware Tools version matters. Upgrade to the latest Tools version for ESXi 7.0.

One more thing: don't set CPU limits on every VM. That defeats the purpose of elastic scheduling. Only limit the bully VM. For VMs with unpredictable bursts—like web servers—leave them unlimited. They'll grab CPU when they need it and give it back when they don't.

If you've done all this and one VM still starves the others, check the hypervisor logs: /var/log/hostd.log on the ESXi host. Search for CPU scheduling errors. Sometimes a VM's configuration got corrupted. Delete and recreate the VM from the template. That's rare but I've seen it fix a stalling issue that nothing else could.