VMware ESXi and vSphere Cluster Management

Understanding Expandable Reservations in VMware vSphere Resource Pools

Learn how VMware vSphere Expandable Reservation lets resource pools obtain reserved CPU or memory capacity from parent pools during admission control.

A vSphere resource pool is a logical allocation boundary for CPU and memory. It groups virtual machines or nested resource pools and applies resource policies to that group. Resource pools are commonly used to separate departments, applications, or service tiers within a host or cluster.

This lesson explains Expandable Reservation, a resource-pool setting that allows an unmet reservation requirement to obtain backing capacity from parent resource pools. It is especially important when resource pools are nested and virtual machines have reservations that exceed the child pool's explicitly configured reservation.

Resource pool reservation fundamentals

A resource pool is a logical grouping used to allocate and manage CPU and memory for virtual machines and nested pools. A pool can have its own reservation, limit, and shares, independently of the settings on individual VMs.

A reservation is a guaranteed amount of capacity. A CPU reservation is commonly expressed in MHz, while a memory reservation is commonly expressed in MB or GB. When a VM is powered on or its reservation is increased, vSphere performs admission control: it checks whether the requested guaranteed capacity can be backed by the resource hierarchy.

A pool-level reservation and a VM-level reservation are different:

• A resource-pool reservation reserves capacity for the workloads assigned to that pool and, where applicable, its descendant pools.
• A VM reservation guarantees capacity directly for one virtual machine.
• The pool's reservation does not automatically replace or remove reservations configured on its VMs.
• The aggregate VM reservation demand may exceed the child pool's configured reservation, which is the situation in which expandable behavior can matter.

CPU and memory are evaluated independently. A pool might have enough CPU reservation backing but insufficient memory backing, or the reverse. Always calculate and review the two resource types separately.

What Expandable Reservation does

Expandable Reservation is a resource-pool option that permits a pool to satisfy a reservation shortfall by drawing available reservation capacity from its parent pool. The setting does not create CPU, memory, hosts, or virtual machines. It changes where vSphere may look for backing capacity during admission control.

This is useful in nested designs. For example, an application pool may have a modest local reservation, while the VMs inside it have reservations that vary with application demand. With expansion enabled, the child can use its own reserved capacity first and then seek additional backing from eligible ancestors.

The behavior is relevant when vSphere evaluates whether a VM can be powered on with its reservation or whether an existing VM reservation can be increased. It is not a general request for extra performance merely because a parent currently has idle resources.

Reservation expansion path

Resource pools form a parent-child hierarchy. A host or cluster has a root resource pool, which is the top-level pool for that resource hierarchy. User-created pools can be children of the root or of another user-created pool.

1. The child pool first uses its own available reserved capacity.
2. If that capacity is insufficient and expansion is permitted, vSphere evaluates the immediate parent.
3. If the parent cannot cover the complete shortfall, the request may continue to higher ancestor resource pools.
4. The search ends when the shortfall is covered, the root resource pool is reached, or the first relevant ancestor with Expandable Reservation disabled is encountered.

An ancestor resource pool is any pool higher in the hierarchy, including the root resource pool. An ancestor must have capacity available to contribute. Enabling Expandable Reservation alone does not manufacture physical CPU or memory resources or override existing reservations, limits, placement constraints, or other admission requirements.

Resource pool hierarchy and reservation flow example

Hierarchy level | Resource pool | Configured CPU reservation | Available capacity for expansion | Expandable Reservation enabled | Role

Root | Root resource pool | 4,000 MHz | 1,000 MHz | Yes | Final eligible source in this example

Parent | Department pool | 2,000 MHz | 800 MHz | Yes | First ancestor evaluated for the child shortfall

Child | Application pool | 1,200 MHz | 0 MHz local surplus | Yes | Uses local reservation, then requests parent backing

Worked CPU reservation calculation

Consider a departmental parent pool containing a child Application pool. The child contains four VMs. Each VM has a CPU reservation of 500 MHz.

VM reservation demand calculation

Virtual machine | CPU reservation (MHz) | Running total reservation demand

Application-VM-1 | 500 | 500

Application-VM-2 | 500 | 1,000

Application-VM-3 | 500 | 1,500

Application-VM-4 | 500 | 2,000

The child Application pool has a configured CPU reservation of 1,200 MHz. The combined VM reservation demand is therefore:

Total VM demand = 4 × 500 MHz = 2,000 MHz
Child-pool reservation = 1,200 MHz
Shortfall = 2,000 MHz − 1,200 MHz = 800 MHz

If the parent departmental pool has at least 800 MHz of available capacity for reservation expansion and the expansion policy permits the request, the parent can supply the 800 MHz shortfall. The VM power-on or reservation-increase request can then satisfy the reservation requirement.

If the immediate parent can supply only part of the shortfall, the request may continue upward to higher ancestors. Every relevant pool on that path must permit expansion, and the ancestors must collectively have enough available capacity. If the required capacity cannot be found, admission control denies the VM power-on or reservation-related request.

Effect of disabled expansion

A pool with Expandable Reservation disabled cannot obtain additional reservation backing from its parent for that request. A child may therefore fail admission even when an ancestor or the cluster appears to have unused resources. The reservation hierarchy and its settings can prevent that unused capacity from being used for the child.

An expansion-disabled ancestor forms a boundary. For example, if the Application pool needs 800 MHz, its immediate parent has only 300 MHz available, and that parent has expansion disabled, vSphere cannot continue to the root to find the remaining 500 MHz. The request fails unless the child and permitted parent capacity already cover the requirement.

Outcome by configuration state

Child has enough local reservation | Parent has available capacity | Expansion enabled along path | Expected admission outcome

Yes | Not relevant | Not relevant | Admission can succeed, subject to other checks.

No | Yes | Yes | Parent or higher ancestors may back the shortfall.

No | Yes | No | Admission stops at the disabled boundary and may fail.

No | No | Yes | Expansion is permitted, but there is no capacity to contribute; admission fails.

Expandable Reservation compared with other resource controls

Resource-pool settings work together, but they have different purposes.

Reservations, limits, shares, and Expandable Reservation

Control | Primary purpose | Guarantees capacity | Caps consumption | Affects contention priority | Propagates reservation requests upward

Reservation | Sets guaranteed CPU or memory backing | Yes | No | Indirectly, by reserving capacity | Only through expandable pool behavior

Limit | Sets a maximum consumption amount | No | Yes | No | No

Shares | Sets relative priority during contention | No | No | Yes | No

Expandable Reservation | Allows a pool's reservation shortfall to seek parent backing | Does not create capacity; it locates backing | No | No | Yes

• Reservations provide guaranteed capacity.
• Limits cap how much CPU or memory a VM or pool may consume, even if more capacity is idle.
• Shares provide relative priority when workloads compete for a constrained resource.
• Expandable Reservation concerns backing a reservation through the resource-pool hierarchy.

A successful reservation expansion does not bypass a restrictive limit. Review limits, shares, and reservations together. A request may obtain reservation backing but still behave differently from expectations because a pool or VM limit caps consumption.

Operational risks and design guidance

A child pool can consume a substantial portion, and potentially all, of its parent's uncommitted reservation capacity. This can reduce the guaranteed capacity available to sibling pools and their workloads.

For example, a scale-out event might allow one application pool to borrow most of the parent's available reservation. A sibling pool may later be unable to power on a reserved VM, even though the sibling exists in the expected hierarchy and the cluster appears to have spare instantaneous capacity.

• Set intentional reservation budgets at each hierarchy level.
• Estimate concurrent VM reservation demand for every child and sibling pool.
• Use Expandable Reservation deliberately rather than enabling it everywhere by default.
• Avoid unnecessarily deep or overly complex pool hierarchies; each additional level makes capacity analysis harder.
• Document pool ownership, expected VM reservations, parent budgets, and the intended expansion policy.
• Test admission behavior with a controlled VM before applying changes to production workloads.
• Recheck both CPU and memory, because expansion success for one resource does not imply success for the other.

Administration workflow in the vSphere Client

1. Select the cluster or host inventory object that contains the resource-pool hierarchy.
2. Locate the target child resource pool and open its resource-allocation or settings view.
3. Review the child pool's CPU and memory reservations, limits, shares, and Expandable Reservation setting.
4. Review the VM-level CPU and memory reservations contributing to the child pool's admission requirement.
5. Map the complete parent chain from the child to the root resource pool.
6. Review each parent pool's reservation, available capacity, limits, shares, and Expandable Reservation setting.
7. Identify the first ancestor where expansion is disabled and treat it as the search boundary.
8. Calculate aggregate reservation demand, compare it with the child reservation, and then compare the shortfall with eligible parent capacity.
9. Check CPU and memory independently before enabling or disabling the setting.
10. Apply the intended configuration and validate it with a controlled VM power-on or reservation-change test.

The exact labels can vary by vSphere version and client view, but the relevant work is performed in the selected resource pool's resource allocation or settings area. Review the parent and child rather than changing only the child setting.

Troubleshooting reservation admission failures

A reserved VM cannot be powered on despite apparent cluster capacity

Possible causes include insufficient local reservation backing, Expandable Reservation being disabled on the child or an ancestor, no remaining parent capacity, a restrictive limit, a host placement constraint, or another admission-control condition.

1. Check the VM's CPU and memory reservation values.
2. Calculate aggregate reservation demand in the target pool.
3. Trace the resource-pool ancestry to the root.
4. Review expansion settings and available reservation capacity at every level.
5. Check CPU and memory separately.
6. Review limits and placement constraints in addition to reservations.

A sibling later fails admission

Another child may have consumed the parent's available reservation through expandable behavior. Review reservation commitments for all sibling pools and their VMs, identify recent VM power-ons or reservation changes, and rebalance pool reservations or revise the hierarchy policy.

Enabling expansion does not resolve the failure

Confirm the complete expansion path and its stopping point. No ancestor may have sufficient available capacity, or an expansion-disabled ancestor may stop the search. The actual cause may also be a limit, host placement constraint, or another admission-control condition rather than the child-pool reservation.

Exam-relevant notes

• Expandable Reservation allows a child pool to seek reservation backing from its parent; it does not create extra physical resources.
• The child uses its own available reserved capacity first.
• The request can move upward through ancestors only while the applicable expansion policy permits it.
• The root resource pool is the top of the search path.
• A disabled ancestor can prevent descendants from using otherwise available higher-level capacity.
• Reservations, limits, and shares are different controls.
• CPU and memory reservation checks are independent.
• Admission control can deny a power-on or reservation increase when the hierarchy cannot back the requested guarantee.

Summary

Expandable Reservation gives a nested resource pool controlled access to reservation capacity in its parent hierarchy when the child's own reservation is insufficient. In the example, four 500 MHz VM reservations require 2,000 MHz, while the child has 1,200 MHz, leaving an 800 MHz shortfall. An eligible parent can supply that shortfall if it has at least 800 MHz available and expansion is permitted along the path.

The setting must be designed with care. Parent capacity is shared, so one expanding child can reduce the reservation capacity available to siblings. Review the full hierarchy, calculate CPU and memory demand independently, account for limits and shares, document ownership and budgets, and test admission behavior before changing production resource pools. For related admission-control concepts, see Admission Control Explained and Admission Control Policy.