CPU Shares in VMware vSphere : A Complete Guide to Prioritizing Your VMs

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

  • Low (500 shares/vCPU)

  • Normal (1,000 shares/vCPU)

  • High (2,000 shares/vCPU)

• 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

1. 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

2. 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.

3. 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

• Cluster Root Pool (entitled to 100% of cluster CPU)

  • Pool A: High shares (8,000)

  • Pool B: Low shares (2,000)

  • Result: Under contention, Pool A gets 80% of cluster CPU, Pool B gets 20%

• Inside Pool A

  • VM A1: 1,000 shares

  • VM A2: 2,000 shares

  • Result: Pool A’s 80% CPU is split 1:2 between A1 and A2 (≈26.7% vs. 53.3% of total cluster CPU)

• Inside Pool B

  • VMs share Pool B’s 20% entitlement according to their own share settings, without affecting Pool A or its VMs.

Prioritizing a Smaller VM over a Larger One

To make a 4‑vCPU VM outrank a 16‑vCPU VM:

1. 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.

2. 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.