Picture a restaurant kitchen with one busy stove. The head chef gets a burner reserved for her at all times, even on a quiet night. The new intern is told he may never use more than one burner, no matter how empty the kitchen gets. And when every burner is lit and a fresh order lands, who gets the next free flame comes down to who holds the most seniority tickets. That kitchen is your ESXi host. Those three rules are reservations, limits and shares, and once you see them this way the Resource Allocation settings stop being scary.
Three controls, three different jobs
A host has finite CPU, counted in megahertz (MHz), and finite memory, counted in megabytes (MB). When the VMs you have powered on want more than the hardware can serve at that instant, vSphere has to referee. It follows three rules at once: it never lets a VM drop below its guaranteed floor, it never lets a VM climb above its ceiling, and any spare capacity in between gets handed out by priority. Reservation is the floor. Limit is the ceiling. Shares are the priority.
Here is the single most misunderstood point, and it trips up almost every fresher: shares do nothing while the host has spare capacity. If there is enough CPU and RAM to go around, every VM gets what it asks for and the share numbers are ignored. Shares only bite during contention, the moment demand is greater than supply. People set shares expecting a permanent effect and then wonder why nothing changed. Nothing changed because the host was never under pressure.
Reservations: the floor you can stand on
A reservation is an amount of CPU or memory the host promises a VM will always have, contention or not. Set a 4 GB memory reservation and 4 GB of real, physical RAM is locked aside for that VM. No other VM can borrow it, even while your reserved VM sits idle. That guarantee is the whole point: it is for the database or the domain controller that must never starve.
Admission control will block a power-on
This is the real-world detail nobody tells freshers until it bites them. The resources behind a reservation must be available the instant the VM powers on. If they are not, the VM simply refuses to start and vCenter throws an insufficient resources error from admission control. It is not a warning you can click past. Say you have a host with 128 GB of RAM and you reserve 16 GB on each of eight VMs. That is 128 GB spoken for. The ninth VM, even a tiny one, will not power on, because there is no unreserved memory left to guarantee. Over-reserving is the fastest way to paint yourself into a corner, and it also shrinks the headroom vSphere HA needs to restart VMs after a host failure.
Limits: the ceiling that quietly hurts
A limit caps what a VM can consume even when the host is wide open and idle. A CPU limit is set in MHz, a memory limit in MB. On paper it sounds responsible. In practice it is the control I trust least, and here is the failure mode every senior engineer has seen.
The memory limit that causes swapping
Suppose you configure a VM with 8 GB of RAM but set a memory limit of 4 GB. The guest operating system sees 8 GB and happily uses it. The moment the guest crosses 4 GB of actual usage, vSphere refuses to back the rest with physical RAM. It reclaims memory first by ballooning, then by host swapping to disk. Your VM grinds to a crawl, applications time out, and the worst part is the host has free RAM sitting right there. The limit forbids touching it. A fresher debugging this sees a slow VM and a host with spare memory and cannot work out why. The fix is almost always to remove the memory limit and size the VM correctly instead.
A real opinion
I disagree with the common habit of setting limits to play it safe. Limits are the control I reach for last, not first. They waste capacity you paid for and they create performance mysteries that eat hours of troubleshooting. Reservations and shares together solve almost every prioritisation problem you will actually meet. A limit earns its place in narrow cases, like capping a noisy test VM that someone keeps running benchmarks on. If you are setting limits on production VMs, stop and ask what you are really trying to fix.
Shares: priority, but only when it is tight
Shares express relative importance among siblings, meaning VMs or pools with the same parent. The defaults are tied to the size of the VM, which surprises people. Every VM is born with a Normal setting, and Normal means a fixed number of shares per unit of resource.
| Setting | CPU shares per vCPU | Memory shares per MB | Ratio |
|---|---|---|---|
| High | 2000 | 20 | 4 |
| Normal | 1000 | 10 | 2 |
| Low | 500 | 5 | 1 |
High, Normal and Low keep a 4:2:1 ratio. A four vCPU VM set to Normal carries 4000 CPU shares. Because shares scale with size, a big Normal VM can out-prioritise a small High VM by accident, which is a good reason to use custom share values when you really care about the outcome.
Worked example
Two single vCPU VMs are pinned at 100 percent on a saturated host. VM-A is set to High (2000 shares), VM-B to Normal (1000 shares). Total shares in play: 3000. VM-A is entitled to 2000 divided by 3000, which is two thirds of the contested CPU. VM-B gets one third. If the host can deliver 6000 MHz to this pair, VM-A receives about 4000 MHz and VM-B about 2000 MHz. Drop the host out of contention and both go back to getting whatever they ask for.
Resource pools: managing groups, not VMs one by one
Setting reservations, limits and shares on every VM by hand does not scale past a handful. A resource pool is a container with its own reservation, limit and shares that you drop VMs into. Put your Production VMs in a High-share pool and your Dev VMs in a Low-share pool, and during a crunch Production wins as a group without you touching a single VM.
One feature worth understanding early is the expandable reservation. When a pool uses up its own reserved capacity, an expandable reservation lets it borrow unreserved resources from its parent rather than failing a power-on. It is convenient, but it also means a pool can quietly consume more than its named reservation, so do not treat the pool reservation as a hard cap on the group.
Worked example with the math
A cluster has two pools. Prod is set to High (8000 shares), Dev to Normal (4000 shares). Total 12000. During contention Prod gets 8000 of 12000, which is two thirds of cluster CPU, no matter how many VMs sit inside it. Dev gets one third. Now look inside Prod: that two thirds is split again among Prod’s own VMs by their shares. So a single Dev VM running alone can still get plenty when Prod is quiet, but the moment everyone is busy, the pool boundary decides the big split first.
Real interview question
What is the difference between a reservation and a limit, and what happens if you set a memory reservation the host cannot satisfy?
Answer it cleanly: a reservation is a guaranteed minimum the host must always provide; a limit is a hard maximum a VM can never exceed. Then show you know the failure mode. If you set a reservation the host cannot back at power-on, admission control blocks the VM from starting with an insufficient resources error. That last sentence is what separates someone who memorised a definition from someone who has actually run vCenter.
Try it yourself
In a free home lab (VMware Workstation, or nested ESXi if you have it), build a small Linux VM. Edit its settings and set a CPU limit of 500 MHz. Boot it and run a busy loop, for example yes > /dev/null in a terminal, to peg one core. Open the VM’s CPU performance chart and watch usage flatline near 500 MHz no matter how hard the loop runs. Now remove the limit and run it again; the line climbs to whatever the core can deliver. You just saw a limit throttle a VM with your own eyes, which is the fastest way to never misuse one in production.
The three controls at a glance
| Control | What it does | When it applies | Main risk |
|---|---|---|---|
| Reservation | Guarantees a minimum | Always reserved | Over-reserving blocks power-ons |
| Limit | Caps a maximum | Always, even when idle | Swapping and wasted capacity |
| Shares | Sets relative priority | Only under contention | Scale with VM size, easy to misjudge |
FAQ
Do I need to set shares, limits and reservations on every VM?
No. The defaults (Normal shares, no reservation, no limit) are fine for most VMs. Only reach for these controls when a specific VM must be protected, prioritised or capped. Tuning everything by hand creates more problems than it solves.
Why is my VM slow when the host has plenty of free RAM?
Check for a memory limit set below the VM’s configured RAM. That forces ballooning and host swapping while real memory sits unused. Remove the limit and the symptom usually disappears.
Do shares work all the time?
No. Shares only matter when VMs are competing for a resource that is in short supply. With spare capacity, every VM gets what it asks for and share values are ignored.
What is an expandable reservation in a resource pool?
It lets a pool borrow unreserved capacity from its parent when its own reservation is used up, so child VMs can still power on. It is handy but means the pool can use more than its stated reservation.
Reservation or shares to protect a critical VM?
Use a reservation when the VM must never starve, full stop. Use shares when you only want it to win during contention but are happy for it to share freely the rest of the time. Many setups use a modest reservation plus High shares together.
CPU and memory do not behave the same
A trap freshers fall into is assuming these three controls act identically on CPU and on memory. They do not, because the two resources are reclaimed differently. CPU is easy to take back: if a VM is not using its cycles right now, the scheduler simply hands them to someone else this instant, and gives them back a moment later. There is almost no penalty for being wrong about CPU shares, because the effect is immediate and reversible.
Memory is sticky. Once a guest writes data into RAM, the host cannot just yank it away without consequences. It has to reclaim gently, through transparent page sharing, ballooning, compression, and finally swapping to disk, each step slower than the last. That is why a bad memory limit hurts so much more than a bad CPU limit, and why memory reservations matter most for latency-sensitive workloads like databases. When in doubt, be generous with memory reservations on the few VMs that truly need them, and leave CPU to shares. The cost of a mistake is far lower on the CPU side.
References
- Broadcom TechDocs: Configure Your Resource Allocation Settings in vSphere
- Broadcom TechDocs: Managing Resource Pools with vSphere
- 4sysops: Understanding vSphere shares, reservations, and limits
About The Author
DrJha