Resource-pool shares first divide resources between sibling pools, then the VMs inside each pool compete within that allocation. Two equally weighted pools do not automatically give every VM beneath them equal entitlement. A VM in a busy five-VM pool can therefore have a different relative entitlement from the only VM in the other pool, despite both pools displaying Normal.
This is a source-researched explanation of vSphere 8.0 CPU shares. No workload test or resource-pool change was performed. The arithmetic is an explicitly simplified example, not a prediction of application throughput.
Read the hierarchy before comparing the labels
The resource-pool guide defines parent, child and sibling objects. A pool can contain VMs, child pools or both. Each host or DRS cluster also has a root resource pool, even though that root is not shown as a separate inventory object.
Resource Allocation Shares states that share comparisons make sense among siblings with the same parent. Their allocation is bounded by reservations and limits. Comparing a VM's numeric weight directly with a VM under another parent skips one or more allocation levels.
Shares express relative importance during contention. They are not a fixed CPU cap. If the relevant demand is absent, the simplified contention split need not describe the resources a VM can use. A configured limit, by contrast, is an upper bound and can create a different problem even when host resources appear free.
The shares guide computes a resource pool’s High/Normal/Low values as if it were a VM with four vCPUs and 16 GB of memory. A VM and a pool directly under the same parent therefore need a separate comparison; the worked example below is limited to two sibling pools with equally weighted VMs inside them.
A two-level worked example
Assume one parent has two child pools, Interactive and Batch. Scalable shares are disabled. Both pools have the same numeric CPU share value; neither has a binding limit or reservation. Interactive contains five powered-on VMs, Batch contains one. All six have equal per-VM CPU shares and sufficient demand to contend.
Under those deliberately simplified assumptions:
| Allocation boundary | Illustrative entitlement |
|---|---|
| Parent to Interactive | One half of the resources contested by the two pools. |
| Parent to Batch | The other half. |
| Interactive to each of its five VMs | One fifth of its half, or 10% of the parent-level total in this model. |
| Batch to its sole VM | Its pool's half, or 50% in this model. |
The discrepancy is not explained by the guest operating systems or equal VM counts on hosts. It follows from the chosen hierarchy and weights. Nor does it prove that the Batch VM runs an application five times faster: workload demand, other constraints and execution behaviour still matter.
The example deliberately excludes scalable shares. The Create a Resource Pool guide describes shares that scale as VMs are added or removed, with scaling at the parent level. Applying the static arithmetic to a differently configured parent would be a diagnostic mistake.
Inspect the actual resource contract
Prerequisites are approved read access to the affected VM, its full ancestor chain and existing performance evidence for the complaint interval. Record vCenter/ESXi versions, parent pool, sibling pools and powered-on VMs, numeric CPU shares, limits, reservations and scalable-shares settings. Do not move a VM between pools merely to observe a different result.
Inspect both pool weights and VM weights. For VMs, the source documents Normal CPU shares as 1,000 per vCPU. Thus two VMs labelled Normal can have different numeric weights because they have different vCPU counts. Use the actual values and topology instead of treating the UI label as a universal unit.
Then establish whether the incident includes demand at the relevant parent boundary. Existing CPU Ready and demand evidence can support a contention investigation, but one host average cannot establish a particular pool's entitlement throughout an incident. Record missing evidence as missing, not as zero demand.
Use the owner’s existing pool configuration record to establish whether scalable shares are enabled. The captured guide documents the checkbox when creating a resource pool; it does not establish a read-only edit-navigation route for an existing pool. If the current setting cannot be read through the approved view, record it as unknown rather than opening a creation workflow.
Decide which policy was intended
If the organisation intended equal aggregate budgets for two departments, the static pool split may be correct even when their VM counts differ. If it intended comparable priority per VM as population changes, the static design may not express that policy. Scalable shares are a documented alternative to evaluate, not an automatic repair to enable from this article.
A binding limit or reservation changes the interpretation and may need to be addressed first. Increasing a VM's shares within its pool does not remove every constraint imposed by its ancestors. Adding vCPUs to gain more default shares also changes VM sizing and scheduling requirements; it is not a clean substitute for deliberate policy.
Acceptance and reversal
The diagnostic output is the actual tree, numeric weights, relevant constraints and a calculation whose assumptions match that configuration. Any future change needs the service owner's intended allocation and a separately authorised measurement of the same workload interval. No latency or throughput improvement is claimed here.
Preserve previous hierarchy and allocation values before a reviewed change. Restoring them can restore the policy, but cannot undo work delayed during contention. Inspection itself requires no rollback, and no production contention test is justified by this example.
Learning notes
- Shares are relative to siblings, not globally comparable priorities.
- Equal pool weights can produce unequal per-VM entitlement.
- Scalable shares, reservations, limits and demand determine whether simple arithmetic applies.
References
- A09-D0: Managing Resource Pools with vSphere
- A09-D2: Resource Allocation Shares
- A09-D3: Create a Resource Pool