VMware ESXi and vSphere Cluster Management

How VMware vSphere Resource Pools Work

Learn how vSphere resource pools allocate CPU and memory using reservations, limits, shares, expandable reservations, and hierarchical contention rules.

A VMware vSphere resource pool is a logical allocation boundary for CPU and memory. It groups virtual machines (VMs) and can also contain child resource pools. Administrators use pools to organize workloads and control how resources are reserved, limited, and prioritized.

Resource pools do not create additional physical CPU or memory. They divide the capacity supplied by an ESXi host or an applicable cluster context.

How the Resource Pool Hierarchy Works

The top-level pool is the root resource pool. On a standalone ESXi host, it represents the host's available CPU and memory resources. In a larger vSphere structure, the applicable root context can allocate resources to child pools.

A child resource pool is created beneath a parent pool. A child receives resources from its parent, and VMs placed in that child consume resources through it.

Root resource pool (ESXi host)
├── Engineering resource pool
│   ├── Eng-Test VM
│   └── Eng-Prod VM
└── Operations resource pool

• Sibling resource pools compete with one another at their immediate parent level.
• VMs inside a pool compete with one another within that pool.
• A VM's effective access to resources depends on its own settings and every relevant parent pool.
• Shares are relative to the immediate parent context. A VM's shares are not compared directly with every VM on the host.

Reservations, Limits, Shares, and Expandable Reservations

CPU and memory have separate resource controls. A pool or VM can therefore have one set of CPU values and another set of memory values.

Reservation

A reservation is a configured minimum amount of CPU or memory intended to be guaranteed to a pool or VM. The reservation is not the same as constant consumption: a VM may reserve capacity without actively using all of it.

Reservations must be supportable by the parent hierarchy. If parent capacity is already committed, a new reservation may not be satisfiable.

Limit

A limit is a ceiling. If a pool has a 4,000 MHz CPU limit, workloads in that pool cannot collectively consume more than 4,000 MHz through that pool, even if the host has idle CPU.

Limits apply independently from shares. A VM with high shares still cannot consume beyond a limit on the VM or any restrictive parent pool.

Shares

Shares are relative weights used when sibling objects need more resources than are available. They do not reserve CPU or memory, and they do not improve performance when there is no contention.

Common share levels in the vSphere Client are typically labeled Low, Normal, and High, although administrators can also work with explicit share values. The important rule is the ratio among siblings, not the label alone.

Expandable Reservations

When expandable reservation is enabled, a child pool may request additional reserved capacity from its parent if its configured reservation alone is insufficient for its VMs or descendants. The parent must have enough available reservable capacity, and the request must remain valid throughout the hierarchy.

Expandable reservations are not a limit. They do not cap consumption. They are also not shares: they do not establish a relative priority during contention. They affect how reservation capacity can be obtained from the parent.

Share-Based Allocation During Contention

Contention occurs when demand for CPU or memory exceeds the capacity available to competing objects. Only then do shares determine proportional priority.

For sibling objects, the allocation fraction is:

Object's share fraction = Object's shares / Total shares of all competing siblings

Suppose two VMs compete inside the same resource pool:

Thus, Eng-Prod receives approximately twice the contested CPU allocation of Eng-Test. This ratio applies to the CPU made available to the Engineering pool, not automatically to all CPU capacity in the host.

What Happens When You Add a Sibling Pool?

Adding a resource pool changes competition at the parent level. The new pool's shares are compared with the shares of existing sibling pools, not with the shares of VMs inside those pools.

Allocation occurs in two stages:

1. Parent-to-pool allocation: The root pool distributes contested capacity among sibling resource pools according to their relative shares and other resource controls.
2. Pool-to-VM allocation: Each child pool distributes the capacity it receives among its VMs according to their relative shares and controls.

For example, if Engineering and Operations are sibling pools with 1,000 CPU shares each, they may receive approximately equal portions of contested root-level CPU, assuming comparable reservations, limits, and demand. Engineering's VMs still retain their internal 2:1 ratio, but that ratio applies only to Engineering's reduced allocation.

Worked Example: Engineering on a Standalone ESXi Host

Consider a standalone ESXi host with the following root capacity:

• CPU capacity: 12,000 MHz
• Memory capacity: 4 GB

Create an Engineering child resource pool with:

• CPU reservation: 1,000 MHz
• CPU limit: 4,000 MHz
• Expandable reservation: Enabled

Place two VMs in Engineering:

• Eng-Test: 1,000 CPU shares
• Eng-Prod: 2,000 CPU shares

Inside Engineering

During CPU contention inside Engineering, the VMs have 3,000 total shares. Eng-Test has one-third and Eng-Prod has two-thirds. If Engineering has 3,000 MHz available for these VMs, the approximate split is:

• Eng-Test: 3,000 × 1/3 = 1,000 MHz
• Eng-Prod: 3,000 × 2/3 = 2,000 MHz

The actual result depends on VM demand, reservations, limits, and the CPU capacity allocated to Engineering. If the VMs do not demand all available CPU, the share ratio does not force them to consume it.

After Adding a Sibling Pool

Now create an Operations sibling pool under the same root and assign it 1,000 CPU shares. Engineering and Operations have equal parent-level share weight. Under root-level CPU contention, Engineering may receive approximately half of the contested allocation and Operations approximately half, assuming comparable settings and demand.

With 12,000 MHz of contested host CPU, a simple equal-share illustration gives Engineering an initial entitlement of approximately 6,000 MHz. However, Engineering has a 4,000 MHz limit, so it cannot consume more than 4,000 MHz through that pool. The unused or inaccessible portion may be available to other eligible workloads according to the hierarchy and scheduling rules.

Within Engineering, Eng-Prod still receives approximately two-thirds and Eng-Test one-third of the CPU Engineering can use under contention. Adding Operations changes the first-stage allocation; it does not change the internal 2:1 ratio.

Configuration in the vSphere Client

1. Select the ESXi host or parent resource pool where the new pool should be created.
2. Create a child resource pool.
3. Configure CPU and memory reservations, limits, and shares for the pool.
4. Enable or disable expandable reservations according to the parent-capacity design.
5. Move or assign VMs to the resource pool.
6. Configure per-VM CPU and memory share values when VMs need different relative priorities.

Review both CPU and memory settings. A CPU reservation does not reserve memory, and a memory limit does not limit CPU. Each resource type is evaluated separately.

Operational Cautions

• Excessive reservations can commit too much capacity and reduce the scheduler's flexibility.
• Restrictive limits can cause avoidable throttling, even when the host appears to have unused capacity.
• Shares matter only when the relevant resource is contested.
• Shares must be interpreted among the correct siblings at the immediate hierarchy level.
• Expandable reservations cannot obtain capacity that the parent hierarchy does not have available.
• Validate the complete resource-pool hierarchy before changing reservations, limits, or shares.

Troubleshooting Resource Pool Behavior

A high-share VM does not receive the expected percentage of total host CPU

Its shares may be relative only to sibling VMs in its immediate pool. The parent pool may itself receive only part of the host's contested CPU.

• Inspect the VM's parent resource pool.
• Inspect sibling resource pools and their parent-level shares.
• Confirm that host-level CPU contention exists.

A workload cannot consume available CPU

A CPU limit on the VM or one of its parent pools may be restricting consumption.

• Review the VM-level CPU limit.
• Review limits on every parent resource pool.
• Determine whether the limit is intentional and compatible with the workload.

A pool reservation cannot be satisfied

The parent may lack sufficient reservable capacity, or reservations elsewhere in the hierarchy may consume the available capacity.

• Review reservations throughout the hierarchy.
• Verify available capacity in the parent pool.
• Check whether expandable reservations are enabled and whether the parent can satisfy an expansion request.

Changing VM shares has no visible effect

There may be no CPU or memory contention, so share-based prioritization is not active. A limit may also be the real constraint.

• Confirm actual contention for the affected resource.
• Check VM and parent-pool limits.
• Compare the VM only with its siblings in the same resource pool.

Exam-Relevant Summary

• A resource pool is a logical container and allocation boundary for CPU and memory.
• The root resource pool represents the resources supplied by the ESXi host or applicable cluster context.
• Reservations express guaranteed minimum capacity; limits express maximum capacity.
• Shares are relative priority weights used during contention, not guarantees.
• Expandable reservations allow a child pool to seek additional reservation capacity from its parent when possible.
• Allocation is hierarchical: parent pools are allocated first, then their VMs or child pools.
• A VM's shares do not represent a percentage of all host CPU unless the VM's pool receives all of that host allocation.
• Always evaluate reservations, limits, shares, demand, and every parent level together.

For surrounding administration tasks, review basic ESXi configuration and adding an ESXi host to vCenter Server inventory.