In virtualized environments, not all workloads are created equal. Some applications require guaranteed CPU access under heavy contention, while others can tolerate delays. vSphere’s CPU Shares lets you assign relative priority weights to virtual machines (VMs) so that critical workloads run smoothly when CPU resources are scarce. In this post, you’ll learn:
What CPU Shares are and how they work
The scope of shares within resource pools and clusters
How to calculate and set custom share values per vCPU
What Are CPU Shares?
CPU Shares are a relative metric that the ESXi scheduler uses to allocate CPU time when demand exceeds supply.
Basically, Shares tell ESXi “how much cake” each VM gets when it’s time to cut slices. Your CPUs still run at full GHz; you’re just deciding which VM gets more turns at the table when everyone’s hungry.
Under contention, the ESXi scheduler divides CPU time slices based on each VM’s total share weight.
VMware presets three levels
By default, every VM is set to Normal, meaning 1,000 shares for each virtual processor it has. These default values can be altered per-VM or per-resource-pool in the VM’s “Edit Settings” → “CPU Shares” section.
How CPU Shares Work Under Contention
No Contention: If the ESXi host has sufficient idle CPU capacity, VMware honors VM reservations and immediately grants CPU time as requested, without considering shares
Contention Phase: Once CPU demand exceeds supply—after all reservations are met—ESXi calculates each VM’s ResourceUsagePerShare and schedules CPU time in order of decreasing share entitlement.
Relative Allocation: Suppose three VMs have 2,000, 4,000, and 8,000 shares respectively; under contention, they receive CPU in a 1:2:4 ratio
CPU Shares Are Scoped to Their Parent Container
Resource Pool-Level Scope
When you set shares on a resource pool, you control how much of that pool’s entitled CPU capacity each of its direct children receives.
Sibling Pools: If you have two child pools under the same parent pool (including the cluster’s root pool), their share values dictate what fraction of the parent’s CPU resources each pool may consume under contention.
VMs Within a Pool: Inside that resource pool, each VM’s own share settings then determine how the pool’s allocated CPU is further split among those VMs.
Cluster-Level Scope via the Root Resource Pool
Every DRS cluster automatically has a root resource pool that represents 100% of the cluster’s CPU and memory resources.
All top‑level resource pools you create in the cluster are children of this root pool. Therefore, by setting shares on those top‑level pools, you are effectively prioritizing CPU access across the entire cluster under contention.
Conversely, shares set on a nested pool only affect that subtree— they do not influence sibling pools in other branches of the hierarchy.
Example
Prioritizing a Smaller VM over a Larger One
To make a 4‑vCPU VM outrank a 16‑vCPU VM:
- Boost the 4‑vCPU VM’s Shares
Set to Custom = 20,000 shares total (via UI or PowerCLI).
It now has higher entitlement than the 16‑vCPU VM’s 16,000 shares.
- Or Lower the 16‑vCPU VM’s Shares
- Change it to Low (16 × 500 = 8,000 shares), putting it beneath the 4‑vCPU VM’s default High (8,000 shares) or your custom value.
Conclusion
CPU Shares in VMware vCenter are a powerful yet underutilized tool for workload prioritization. By understanding how shares work—within resource pools and across clusters—and by defining a clear baseline-per-vCPU policy, you can ensure that your mission-critical VMs always get the CPU cycles they need, even under heavy contention.
