A new admin gets a ticket: an application VM feels slow. The instinct is obvious, give it more power, so they bump it from 2 vCPUs to 8 and restart. The next morning the app is somehow worse, and now two other VMs on the same host are sluggish too. Nothing is broken, no error is logged, and the fix that felt right made everything slower. This is the most common trap in virtualization, and once you understand why it happens, half of the beginner mistakes stop being mysterious.
Mistake 1: thinking more vCPUs means more speed
This is the one worth understanding deeply, because the logic behind it explains so much else. A physical host has a fixed number of CPU cores, and every running VM shares them. The ESXi scheduler has to find a free physical core for each virtual CPU a VM wants to run. Here is the catch: a VM with several vCPUs generally needs that many cores free at roughly the same moment to run smoothly. Give a VM 8 vCPUs on a busy host and the scheduler has to wait until 8 cores line up. The VM sits in a queue, ready to run but waiting. That wait shows up as a metric called CPU Ready, and high CPU Ready feels exactly like slowness even though no component has failed.
The numbers that tell the story
CPU Ready is the percentage of time a vCPU was ready to run but had to wait for a physical core. Under roughly 5 percent per vCPU is healthy. Above 5 percent, users start to feel it. Above 10 percent, the application is effectively broken even though the guest OS thinks its CPU is barely busy. There is a sister metric called Co-Stop, which applies only to VMs with more than one vCPU and measures time lost because the scheduler could not run all the vCPUs together. A Co-Stop persistently above 3 percent is a clear sign the VM has too many vCPUs for the host. The fix is the opposite of the instinct: remove vCPUs, not add them.
Worked example: why 8 was slower than 2
Take a host with two 10-core processors, so 20 physical cores, already running a dozen other VMs that keep most cores busy. You give one VM 8 vCPUs. For that VM to run a single instruction cleanly, the scheduler wants 8 cores idle at the same instant. On a busy host that alignment is rare, so the VM spends a lot of time queued.
Drop it to 2 vCPUs and the scheduler only needs 2 cores free, which happens constantly. CPU Ready falls, the app responds faster, and the host has more room for everyone else. The guest OS reported low CPU usage the whole time, which is exactly why the slowness looked like a mystery. The bottleneck was scheduling, not horsepower.
Mistake 2: treating a snapshot as a backup
A snapshot sits on the same storage as the VM and depends on the original disk, so it cannot protect you against the storage failing or the VM being deleted. It also grows the longer it runs and can fill a datastore. A backup is an independent copy on separate storage. New admins keep snapshots for weeks and call it protection, then learn the hard way during an outage. We gave this its own full part because it matters so much. If you only read one other article, read Backups vs snapshots (Part 14). The short rule: take a snapshot before a risky change, remove it within the hour, and rely on real backups for recovery.
Mistake 3: letting a datastore fill up
Thin provisioning lets you create a 200 GB virtual disk that only uses space as data is actually written. It is efficient, and it is also a trap if you forget that the disk can grow. Create ten thin 200 GB disks on a 1 TB datastore and you have promised 2 TB of space you do not have. This is called overcommitment. As long as the VMs stay lightly used you are fine. The day they all grow, the datastore fills, and a full datastore can pause every VM living on it, not just the greedy one. The mistake is not using thin provisioning. The mistake is not watching free space after you do.
| Choice | Thin provisioning | Thick provisioning |
|---|---|---|
| Space used at creation | Only what is written | The full disk size up front |
| Main risk | Overcommit, datastore fills | Wastes space if disk stays empty |
| Good default for | Most workloads, labs, dev | Latency-sensitive, predictable apps |
Mistake 4: skipping VMware Tools
VMware Tools is a small package you install inside the guest operating system. Without it, the VM still runs, which is why beginners skip it, but a lot stops working well. You lose clean shutdown from vCenter, accurate time sync, the optimised network and disk drivers, and the heartbeat that vSphere HA uses to tell whether the guest is alive. A VM with no Tools and a sluggish network card often turns out to be running the generic driver because Tools was never installed. Always install it after building a VM, and keep it updated. It is the cheapest performance and manageability win you will ever get.
Mistake 5: never right-sizing after build day
The first four mistakes share a root cause: a VM is set once and never revisited. Someone copies a template, accepts whatever CPU and memory it came with, and moves on. Months later the environment is full of VMs that are too big, snapshots no one tracks, and datastores quietly creeping toward full. Right-sizing is the habit of checking, every so often, whether a VM actually uses what it was given, and trimming it if not. It is unglamorous and it is the single most valuable thing a junior can do for a vSphere environment, because it gives capacity back to everyone.
Real interview question
"A VM is running slowly. You check inside the guest and CPU usage looks low. What do you look at next?"
Answer like this: low CPU usage inside the guest with a slow-feeling app points to scheduling contention on the host, not a shortage of power. I would check CPU Ready and Co-Stop for that VM in vCenter. If CPU Ready is above 5 percent per vCPU, or Co-Stop is above 3 percent on a multi-vCPU VM, the VM probably has too many vCPUs for how busy the host is, and reducing them usually helps. Naming CPU Ready and resisting the urge to add resources is exactly what the interviewer wants to hear.
Try it yourself
In a free home lab (VMware Workstation or nested ESXi):
1. Build a small test VM and give it far more vCPUs than your host has physical cores, for example 8 vCPUs on a 4-core laptop. 2. Run a light workload and note how it feels. 3. Power off, drop it to 2 vCPUs, and try the same workload.
How to check you got it right: the 2-vCPU version should feel as fast or faster, and in a real ESXi lab the CPU Ready figure in the performance charts will be visibly lower. You have just reproduced the most common production mistake on purpose, which is the best way to never make it by accident.
My honest opinion: default to too small, not too big
Common advice says give a VM a little headroom so it never runs short. I think that advice quietly causes most of the waste and slowness in beginner environments. Headroom on a shared host is not free insurance; it is capacity taken from every other VM, and on the CPU side it can actively slow the very VM you were trying to protect. My rule for newcomers is to start a VM deliberately smaller than you think it needs, two vCPUs unless you have a real reason, then measure and add only when the numbers demand it. Adding a vCPU later is a two-minute change. Undoing a culture of oversized VMs across a whole cluster takes months. Bias toward small.
FAQ
How many vCPUs should I give a new VM?
Start with the smallest sensible number, often 2, unless the vendor of the app states otherwise. Measure CPU Ready and actual usage for a few days, then add one vCPU at a time only if the data shows it is needed. Bigger is not safer here.
Is thin provisioning safe to use?
Yes, for most workloads, as long as you monitor datastore free space and avoid promising far more space than the datastore has. The danger is forgetting you overcommitted, not the feature itself.
What is CPU Ready in plain terms?
It is the time a VM was ready to run but had to wait for free physical cores. High CPU Ready means the host is contended or the VM is too wide. Under about 5 percent per vCPU is the comfortable zone.
Do I really need VMware Tools on every VM?
For any VM you care about, yes. It gives clean shutdown, time sync, better drivers, and the heartbeat HA relies on. Skipping it is a false economy that shows up later as odd performance and management problems.
Why does my VM feel slow when the host CPU looks fine overall?
Average host CPU can look calm while a specific VM suffers high CPU Ready because its vCPUs cannot all be scheduled together. Look at the per-VM CPU Ready and Co-Stop figures, not just the host average.
The memory version of the same mistake
CPU gets the attention, but memory has its own trap, and it is sneakier. ESXi lets you assign more memory across all your VMs than the host physically has, the same overcommitment idea as thin disks. While VMs do not all need their full memory at once, this works fine. When they do, ESXi has to reclaim memory using techniques like ballooning, where a small driver inside the guest (part of VMware Tools) gently pressures the guest to give back pages, and as a last resort swapping to disk, which is slow. A VM that suddenly crawls for no obvious reason is often a host under memory pressure, not a sick application. The lesson is identical to the CPU one: assign what a VM actually uses, watch the host, and treat overcommitment as something you monitor, not something you forget.
Granted is not the same as used
Beginners read the configured memory of a VM and assume that is what it consumes. It is not. A VM granted 16 GB may actively touch only 4 GB, and ESXi is smart enough to give the rest to others until it is needed. This is why you size from measured active usage, not from the number on the VM configuration screen. Judge it from the host and cluster memory charts in vCenter, never from the guest alone, exactly as you do for CPU.
References
- VMware: Performance Best Practices for vSphere 8.0
- Broadcom: Understanding CPU Ready values in the vSphere performance charts
- Broadcom: Best practices for using VMware snapshots
About The Author
DrJha