VMware ESXi and vSphere Cluster Management

Understanding Expandable Reservations in VMware vSphere Resource Pools

Learn how VMware vSphere Expandable Reservation borrows CPU and memory reservation capacity through resource-pool hierarchies, including examples, risks, configuration, and troubleshooting.

What Expandable Reservation Means

Expandable Reservation is a setting on a VMware vSphere resource pool. When the pool's own configured reservation is not enough to satisfy the reservations required by its workloads, the setting allows the pool to obtain additional reservation capacity from its parent resource pool.

This setting applies to reserved CPU and memory capacity. It does not create physical CPU, memory, or cluster capacity. It only permits a reservation requirement to use capacity that is available higher in the resource-pool hierarchy.

Three values must be kept separate:

• Reservation: The guaranteed minimum CPU or memory capacity assigned to a VM or resource pool, subject to available capacity and admission control.
• Current demand: The amount of CPU or memory the workloads are using now. Current demand may be lower than their reservations.
• Limit: The maximum amount of CPU or memory the VM or pool may consume. A limit is not a guarantee.

Shares are another control. They establish relative priority during contention, but they do not guarantee capacity like reservations do.

Resource-Pool Hierarchy

A resource pool is a logical vSphere container used to allocate and control CPU and memory for virtual machines and nested resource pools. Pools form a parent-child hierarchy.

• The root resource pool is the top-level pool representing the resources available to lower-level pools.
• A parent resource pool is directly above another pool and is the first possible source of expanded reservation capacity.
• A child resource pool is nested below a parent and receives an allocation from that parent.
• An ancestor is any pool higher in the hierarchy, including the direct parent and the root.
• A resource pool can contain virtual machines, nested resource pools, or both.

For example, a hierarchy might look like this:

Root resource pool
└── Department resource pool
    └── Application resource pool
        ├── Application VM 1
        ├── Application VM 2
        ├── Application VM 3
        └── Application VM 4

Each child pool receives entitlement from its parent. Consequently, hierarchy design determines which pools can provide additional reserved capacity and which organizational boundaries can block borrowing.

How Reservation Expansion Works

Expansion is considered when the reservations required by workloads in a child pool exceed the reservation directly available to that pool. vSphere evaluates the hierarchy upward:

1. The child pool is checked first.
2. If its direct reservation is insufficient and expansion is allowed, vSphere checks the parent pool.
3. If the parent cannot satisfy the shortfall, the request can continue to successive ancestors when expansion remains permitted along the path.
4. The search ends when sufficient capacity is obtained, when the root is reached without enough capacity, or when an ancestor with Expandable Reservation disabled blocks the request.

For a request to continue beyond an ancestor, that part of the hierarchy must permit expansion. A disabled setting acts as a boundary: capacity above that boundary is not available to the descendant through reservation expansion.

When a child borrows capacity, that capacity comes from what is available to the parent. It can therefore reduce the reservation capacity that remains available to sibling pools. Expansion is not an isolated transaction between the child and the physical cluster; it changes how shared parent capacity is consumed.

Behavior by Hierarchy Condition

Condition | Expandable Reservation state along path | Parent capacity available | Expected outcome

Child pool has sufficient direct reservation | Not needed for this request | Not relevant | The request is satisfied by the child pool's direct reservation.

Child has a shortfall and the parent has sufficient capacity | Enabled on the child and permitted at the required path | Sufficient | The parent contributes the shortfall.

Parent is insufficient but an ancestor can provide capacity | Enabled throughout the required path | Available at a higher ancestor | The request continues upward until enough capacity is found.

An ancestor has expansion disabled | Disabled at the boundary | Capacity may exist above the boundary | The request stops at that ancestor and cannot use capacity above it.

Root is reached without enough capacity | Expansion cannot go higher | Insufficient | Admission fails because the reservation cannot be satisfied.

VM Reservations and Pool Reservations

A VM-level CPU or memory reservation contributes to the reservation requirement of the resource pool containing that VM. When several powered-on VMs have reservations, their requirements are considered together with the pool's directly configured reservation.

A reservation shortfall is the difference between the workload reservation requirement and the reservation directly available to the pool. If the combined reservations of powered-on VMs exceed the pool's direct reservation, Expandable Reservation may be needed.

Admission control determines whether sufficient resources are available before an operation such as powering on a VM. If the reservation cannot be satisfied by the pool, its permitted ancestors, and available cluster capacity, the power-on operation may be rejected.

Reservation, Limit, and Shares

Control | Purpose | Guarantees capacity | Restricts maximum use | Relevant during contention

Reservation | Defines a guaranteed minimum CPU or memory amount | Yes, when admission requirements and capacity are satisfied | No | Yes

Limit | Defines the maximum amount a VM or pool may consume | No | Yes | Yes

Shares | Defines relative priority compared with other workloads | No | No | Yes

Worked CPU Reservation Example

Assume this nested hierarchy:

Root resource pool
└── Department resource pool
    └── Application resource pool
        ├── VM 1: 500 MHz reservation
        ├── VM 2: 500 MHz reservation
        ├── VM 3: 500 MHz reservation
        └── VM 4: 500 MHz reservation

The application pool has a directly configured CPU reservation of 1,200 MHz. Each of its four VMs has a 500 MHz CPU reservation.

Virtual machine | VM CPU reservation | Number of VMs | Combined reservation | Pool direct reservation | Shortfall requiring expansion

Application VMs | 500 MHz | 4 | 2,000 MHz | 1,200 MHz | 800 MHz

The calculation is:

4 × 500 MHz = 2,000 MHz total VM reservation
2,000 MHz − 1,200 MHz = 800 MHz shortfall

If Expandable Reservation is enabled for the application pool and the department pool has at least 800 MHz of available reservation capacity, the department pool can contribute the shortfall. The application pool's total requirement can then be admitted.

If the department pool cannot provide all 800 MHz, the request can continue toward the root resource pool only if expansion remains enabled throughout the relevant path. If a required ancestor has expansion disabled, or if the root cannot provide the remaining capacity, the reservation request cannot be admitted. Depending on the operation, this can prevent a VM from powering on.

What Happens When Expandable Reservation Is Disabled

Disabling Expandable Reservation on a resource pool prevents that pool from obtaining additional reserved capacity from its parent. Descendant requests cannot use that pool as a route to higher-level capacity.

For example, if the department pool has expansion disabled, an application pool below it cannot continue a reservation request from the department pool to the root, even when the root has unused capacity. The department pool becomes an isolation boundary.

This behavior can be useful when:

• A business unit must not consume capacity assigned to other business units.
• Predictable allocation is more important than flexible sharing.
• A parent pool represents a chargeback or ownership boundary.
• Production workloads require a fixed and auditable guarantee.

Capacity-Governance Risks

A broadly expandable hierarchy can allow one child pool with large VM reservations to consume much of its parent's available reservation capacity. Sibling pools may then have less capacity available for their own reservation requests.

Possible effects include:

• A sibling VM failing admission when it attempts to power on.
• Reduced ability to guarantee reservations for later workloads.
• Unexpected changes in which department or application receives shared capacity.
• Difficulty explaining resource ownership during chargeback or capacity reviews.

Expandable reservations should not replace capacity planning or deliberate reservation sizing. Document which pools may borrow capacity, which pools are isolation boundaries, and who owns shared parent pools. Maintain headroom at shared parents so that one workload does not consume every available reservation unit.

When to Enable or Disable Expandable Reservation

Use case | Recommended setting | Reason | Operational consideration

Shared development or test capacity | Enable where appropriate | Unused parent capacity can be shared flexibly | Monitor sibling impact and retain parent headroom.

Strictly isolated business unit | Disable at the boundary | Prevents borrowing across the ownership boundary | Size the direct reservation for expected demand.

Production workloads with fixed guarantees | Usually disable or tightly control | Provides more predictable allocation | Validate reservations against cluster capacity and availability policies.

Nested application pools under a centrally managed parent | Enable only by policy | Allows controlled sharing of centrally managed capacity | Document ownership and review aggregate VM reservations.

Configuration and Verification Workflow

Use the vSphere Client to review or change the resource-pool allocation settings. Exact labels can vary by vSphere release and permissions, but the conceptual workflow is consistent.

1. Select the target resource pool in the vSphere inventory.
2. Open the resource allocation or settings view for the pool.
3. Review CPU and memory reservations, limits, and shares.
4. Locate the Expandable Reservation control for the relevant resource type.
5. Enable or disable it according to the intended borrowing policy.
6. Inspect the parent and ancestor pools. The setting and available reservation capacity across the complete path determine the result.
7. Save the configuration.
8. Validate the change with an appropriately reserved test VM or a controlled power-on operation.

Review CPU and memory independently. A hierarchy may have enough expandable CPU capacity but insufficient memory capacity, or the reverse. A VM requiring both guarantees can still fail admission when only one resource dimension is satisfied.

Configuration Checklist

• Map the complete resource-pool hierarchy from the VM's pool to the root.
• Record direct CPU and memory reservations for every relevant pool.
• Record CPU and memory reservations assigned to VMs in each pool.
• Check available reservation capacity at every potential parent and ancestor.
• Identify any disabled expansion setting that should serve as an isolation boundary.
• Review cluster-level capacity and applicable availability policies before relying on guarantees.
• Test business-critical reservation changes during a maintenance window or with representative workloads.

Validation and Monitoring

After changing the setting, verify the result rather than assuming that enabling it creates capacity.

• Review resource-pool summaries for configured reservations, limits, shares, and current reservation usage.
• Confirm the VM is assigned to the intended resource pool.
• Perform a controlled VM power-on test when the reservation is business-critical.
• Check CPU and memory admission results separately.
• Monitor parent and sibling pools for reduced available reservation capacity.
• Watch for contention and confirm that the resulting behavior matches the resource-allocation policy.

Troubleshooting Expandable Reservation

A VM Cannot Power On After a Reservation Is Configured

Possible causes include an insufficient direct pool reservation, a disabled expansion setting on the pool or an ancestor, insufficient capacity at the parent or root, or an unmet memory reservation even though CPU capacity is available.

1. Compare the VM reservation with the direct reservation and current reservation usage of its pool.
2. Trace the hierarchy from the VM's pool to the root.
3. Inspect Expandable Reservation at every relevant level.
4. Check available CPU and memory reservation capacity independently.
5. Review recent changes in sibling pools that may have consumed shared parent capacity.

Resolution options include increasing a pool or parent reservation when capacity exists, enabling expansion where policy permits it, reducing unnecessary VM reservations, moving the VM to a suitable pool, or adding infrastructure capacity.

A Child Pool Consumes Capacity Intended for Other Workloads

This commonly occurs when expansion is enabled across a broad hierarchy, parent pools have little headroom, or VM reservations in the child pool are oversized.

1. Identify the child pool's aggregate VM reservations and borrowed capacity.
2. Compare current parent capacity with the requirements of sibling pools.
3. Review the hierarchy for expansion paths that cross an intended organizational boundary.

Possible remedies are disabling expansion at the intended boundary, resizing direct reservations, reducing excessive VM-level reservations, and establishing a reservation review procedure.

Enabling Expansion Does Not Resolve the Failure

Expansion cannot resolve a shortage when every permitted ancestor, including the root, lacks capacity. The failure may also be in memory rather than CPU, or may involve a limit, an incorrect VM-to-pool assignment, or insufficient physical and cluster-level capacity.

1. Verify the VM's actual resource-pool assignment.
2. Validate CPU and memory reservation paths separately.
3. Inspect resource-pool limits and the workload's requirements.
4. Confirm available physical and cluster-level capacity.

Corrective actions may include freeing or adding capacity, revising reservations, redesigning the hierarchy, correcting the VM assignment, or adjusting limits only when that matches the resource-management policy.

Operational Best Practices

• Use expansion when controlled sharing of unused parent reservation capacity is intentional.
• Disable expansion where strict isolation, predictable allocation, or departmental chargeback boundaries are required.
• Avoid assigning high VM reservations without validating the complete hierarchy and cluster capacity.
• Maintain headroom at shared parent pools.
• Document borrowing permissions, isolation boundaries, and ownership for shared parents.
• Test changes during a maintenance window or with representative workloads when reservations are business-critical.
• Review CPU and memory independently because their requirements and available capacity can differ.

Exam-Relevant Summary

• Expandable Reservation allows a pool with an insufficient direct reservation to borrow reservation capacity from its parent.
• Borrowing follows the hierarchy upward toward the root, subject to expansion settings and available capacity.
• A disabled ancestor blocks descendant requests from moving higher.
• Borrowed capacity comes from the parent and can reduce capacity available to sibling pools.
• VM reservations contribute to the reservation requirement of their containing pool.
• Reservations, limits, and shares have different purposes: guarantees, maximums, and relative priority.
• CPU and memory admission are evaluated independently.
• Expandable Reservation does not create physical capacity and does not replace capacity planning.

For related reading, see Expandable Reservation Parameter.