VMware ESXi and vSphere Cluster Management

VMware ESXi Resource Pool Attributes: Shares, Limits, Reservations, and Expandable Reservations

Learn how VMware ESXi resource pool shares, limits, reservations, and expandable reservations control CPU and memory allocation during normal operation and contention.

What resource pool attributes control

A resource pool is a logical allocation boundary for CPU and memory. It groups virtual machines (VMs) and can contain nested, or child, resource pools. Administrators use resource pool attributes to control how capacity is prioritized, guaranteed, and capped.

CPU and memory attributes are configured independently. A pool can have high CPU shares but normal memory shares, or a memory reservation without a CPU reservation. Each resource must be evaluated separately because processor demand and physical memory demand can differ substantially.

During normal operation, a host may have enough capacity for every workload, so share settings may not visibly change performance. During resource contention, aggregate demand exceeds available CPU or memory supply. Shares then influence relative access, reservations protect minimum entitled capacity, and limits continue to enforce maximum consumption.

For a broader overview of the terminology used in this lesson, see VMware resource pool attributes.

The resource pool hierarchy

The hierarchy determines where a pool receives capacity and which other pools compete with it.

Hierarchy component	Role	Relationship to child pools	Effect on reservations	Effect on share-based contention
Root resource pool	The top-level allocation view of resources available from the host or applicable compute object.	Provides the highest-level capacity from which subordinate pools receive resources.	Reservations must fit within capacity available at the host hierarchy.	Provides the upper allocation context for descendant pools.
Parent resource pool	A pool that contains one or more child pools or VMs.	Distributes its available CPU and memory capacity to its children.	Its reservation, limit, and available capacity constrain what children can receive.	Its child pools compete relative to their shares when they need more than the parent can provide.
Child resource pool	A nested pool below a parent.	Receives capacity through the parent rather than directly bypassing the hierarchy.	Its reservation must be supportable by its local parent allocation, unless expandable reservation can obtain suitable capacity higher in the hierarchy.	Competes with sibling pools under the same parent.
Sibling resource pools	Pools that share the same direct parent.	Receive allocations from the same parent context.	Their combined requirements must fit the relevant available capacity.	Shares are compared among these competing pools, not indiscriminately across unrelated branches.
Virtual machines within a pool	Workloads that consume the pool's allocation.	Use capacity made available by the containing pool and remain subject to the hierarchy above them.	VM settings and pool settings both affect the effective resources available to the workloads.	VMs are governed by their own priorities within the capacity assigned to the pool.

A parent pool's limit can reduce the maximum capacity available to every child, even when the host has unused resources elsewhere. Likewise, a parent reservation establishes capacity that the parent is entitled to provide to workloads beneath it. A child cannot be evaluated in isolation from these inherited constraints.

Shares: relative priority, not a guarantee

Shares are relative weights used to prioritize competing resource consumers. CPU shares determine relative access to processor capacity, while memory shares determine relative access to physical memory. Shares do not represent a fixed number of CPU cycles or megabytes.

Shares matter when sibling pools have active demand for the same constrained resource. If Production and Development are sibling pools and Production has twice the relevant shares of Development, Production is eligible for a proportionally larger allocation when both are competing for scarce capacity. The exact outcome also depends on demand, reservations, limits, and the rest of the hierarchy.

Shares do not reserve capacity and do not cap usage. A pool with low shares may use substantial idle capacity when other pools are not demanding it. A pool with high shares may still be prevented from using more by a configured limit or by a parent pool's limit.

Example: prioritizing production over development

Create sibling pools named Production and Development beneath the same parent.
Assign Production a larger CPU share value than Development.
Generate safe, controlled CPU demand in both pools until available processor capacity is insufficient.
During contention, Production receives a larger proportional opportunity to use CPU because its share weight is greater.

While the host has spare CPU capacity, both pools may receive all the processor time they request. In that state, the share difference has little or no practical effect. The same principle applies independently to memory shares during memory contention.

Limits: maximum consumption

A limit is the maximum CPU or memory capacity a resource pool may consume. A CPU limit constrains processor capacity, commonly expressed in a CPU capacity unit in the vSphere configuration workflow. A memory limit constrains the host physical memory available to the pool.

A limit remains enforced whether or not the host has contention. Therefore, a pool can perform poorly even when monitoring shows unused host capacity: the pool may have reached its own ceiling, or a parent pool may have imposed a ceiling above it.

A limit differs from a reservation. A limit says, “do not allow this pool to consume more than this maximum.” It does not promise that the pool will receive any minimum amount. Use limits carefully because a restrictive value can create an artificial bottleneck for a workload that could otherwise use idle resources.

Example: containing a noncritical workload

A development or test pool may receive a CPU or memory limit to prevent experiments from consuming all capacity intended for other groups. This provides isolation, but the tradeoff is deliberate throttling: the pool cannot exceed the configured maximum even when the ESXi host has idle resources.

Reservations: guaranteed minimum capacity

A reservation is the minimum CPU or memory capacity guaranteed to a resource pool, provided the reservation is admitted and the hierarchy can support it. CPU reservations protect processor capacity; memory reservations protect host physical memory capacity.

Reservation admission requires sufficient unreserved capacity at the appropriate level of the resource hierarchy. ESXi validates whether the host or parent allocation can support the configured requirement. Aggregate child reservations must also fit within the capacity available to the parent and its ancestors.

A reservation is capacity set aside for possible use. It is not necessarily consumed continuously. If a reserved pool is using less than its entitlement, other workloads may be able to use otherwise available capacity according to ESXi scheduling and configuration rules. The reservation nevertheless protects the pool's minimum entitlement when competing demand occurs.

Reservation compared with shares and limits

Shares: choose relative priority among competing consumers; they do not guarantee a minimum or impose a maximum.
Reservation: establishes a minimum guaranteed entitlement if capacity admission succeeds; it does not define the maximum.
Limit: defines a maximum; it does not guarantee a minimum.

Reservations are appropriate for business-critical workloads that must retain minimum capacity during contention. They should be planned against aggregate demand and future VM growth rather than configured only for today's inventory.

Expandable reservation

Expandable reservation is a resource-pool-specific option that allows a child pool to obtain reservation capacity from its parent or higher ancestors when the child's locally available allocation is insufficient.

Consider a child pool with a configured reservation beneath a parent pool. If the capacity available within the parent's direct allocation cannot satisfy the child's reservation requirement, enabling expandable reservation permits the child to request unused reservable capacity from the parent or ancestor hierarchy, subject to the applicable reservations, limits, and available capacity above it.

When expandable reservation is disabled, the child must satisfy its reservation needs from capacity available within its parent allocation. It cannot expand the reservation request upward to obtain additional capacity from ancestors. This can cause a reservation change to be rejected or prevent the child from obtaining the expected guaranteed capacity.

Nested-pool example

Place a child pool beneath a parent whose locally available reservation capacity is constrained.
Configure a reservation for the child based on the minimum capacity its workloads require.
Enable expandable reservation if the design allows the child to use unused reservable capacity from the parent or ancestors.
With the option disabled, the child must meet the requirement from the parent allocation alone.
Review all ancestor limits and reservations because expandable reservation cannot overcome an actual lack of admissible capacity.

Resource pool attribute comparison

Attribute	Primary purpose	Acts during contention	Guarantees minimum capacity	Caps maximum capacity	Applies to CPU and memory	Key caution
Shares	Set relative priority or weighting.	Yes, when sibling demand exceeds available supply.	No.	No.	Yes, independently.	Shares are not fixed allocations and have little visible effect without contention.
Limits	Set a maximum consumption ceiling.	They remain enforced during and outside contention.	No.	Yes.	Yes, independently.	A low limit can throttle a workload despite idle host capacity.
Reservations	Protect minimum entitled capacity.	Yes, by protecting the admitted minimum.	Yes, if sufficient capacity is admitted.	No.	Yes, independently.	Reservations consume planning capacity and must fit the hierarchy.
Expandable reservation	Allow reservation capacity requests to use parent or ancestor capacity.	It affects reservation fulfillment, not ordinary priority.	It can help satisfy a child reservation from higher levels.	No.	Yes, where supported by the pool configuration.	It is not unrestricted bursting and cannot create capacity that does not exist.

Behavior under CPU and memory contention

CPU contention occurs when VMs and pools collectively demand more processor capacity than the host or applicable parent allocation can provide. Memory contention occurs when active demand for physical memory exceeds available host memory or the allocation available to a pool.

Under contention, shares determine relative access among competing siblings. Reservations protect the minimum entitled capacity that was successfully admitted. Limits remain hard ceilings regardless of contention. These mechanisms can operate at multiple levels: a VM is affected by its own settings, its containing pool, parent pools, and the root resource context.

Comparing four settings on one pool

Suppose a pool has high shares, a CPU reservation, a CPU limit, and expandable reservation enabled. The high shares give it higher relative priority against competing siblings. The reservation protects a minimum CPU entitlement after capacity is admitted. The limit prevents the pool from consuming above its configured maximum. Expandable reservation allows the pool's reservation request to seek support from higher levels when local parent capacity is insufficient.

Repeat the analysis separately for memory. High CPU shares do not increase memory priority, and a CPU reservation does not guarantee physical memory. Every conclusion must identify whether CPU or memory is the constrained resource.

Scenario	Relevant setting	Expected allocation behavior	Potential risk or limitation
Host has spare capacity	Shares	Most demanding pools may use available capacity regardless of relative share differences.	Administrators may incorrectly conclude that shares are ineffective.
Sibling pools have CPU contention	CPU shares, reservations, and limits	Admitted reservations are protected; remaining capacity is influenced by relative shares, subject to limits.	Share comparisons are meaningful only among competing pools in the same allocation context.
A pool reaches its configured limit	CPU or memory limit	The pool cannot consume above its maximum, even if idle host capacity exists.	The limit can cause artificial performance degradation.
A pool needs its reserved capacity	Reservation	The pool receives its guaranteed minimum when the reservation was admitted and hierarchy capacity remains valid.	Insufficient unreserved or parent capacity can prevent admission or fulfillment.
A child pool cannot satisfy a reservation locally	Expandable reservation	The child may seek unused reservable capacity from its parent or ancestors when enabled.	Ancestor limits, reservations, or total host capacity may still prevent fulfillment.
Expandable reservation is disabled	Expandable reservation	The child must satisfy its reservation from capacity available within its parent allocation.	A valid-looking child reservation may be rejected or remain unsupported by the local allocation.

Configuring resource pool attributes in the vSphere Client

The exact labels and available workflows can vary by vSphere version and object type, but the planning sequence is consistent.

Create or select a resource pool beneath an ESXi host or an existing parent resource pool.
Review the hierarchy and confirm that the pool has the intended parent and sibling relationships.
Configure CPU Shares, CPU Reservation, and CPU Limit.
Configure Memory Shares, Memory Reservation, and Memory Limit.
Enable or disable Expandable Reservation where the resource-pool configuration workflow supports it.
Review available and reserved capacity before saving reservation changes.
Monitor usage, contention indicators, and workload performance after applying the settings.

Use controlled competing workload demand for validation only when it is operationally safe. Verify that the observed behavior matches the intended hierarchy, rather than testing only a single VM in isolation.

Configuration planning guidance

Use shares when the primary requirement is prioritization, such as giving production workloads more access than development during contention.
Use reservations when a workload group requires a guaranteed minimum CPU or memory entitlement.
Use limits only when a deliberate maximum is required for containment, chargeback, testing, or isolation. Avoid arbitrary low ceilings.
Use expandable reservation when a nested pool should be able to draw reservation support from unused capacity higher in the hierarchy.
Plan for future VM growth. A design that admits today's reservations may fail when additional VMs or larger reservations are added.
Check aggregate child reservations against parent reservations, limits, and available capacity.
Document whether each setting applies to CPU, memory, or both; the two resources behave independently.
Monitor performance after changes and compare actual demand with configured shares, reservations, and limits.

Troubleshooting resource pool behavior

Poor performance despite apparent unused host capacity

Check the pool's CPU and memory limits first. A restrictive pool limit can cap consumption while the host still reports unused capacity. Then review limits on every parent pool and compare observed usage with each configured maximum.

A high-share pool does not receive more resources

Confirm that real contention exists. If competing pools are not demanding their potential allocations, a high-share pool has no special need to receive more. Also compare shares only among sibling pools in the same parent allocation context, and check for pool or parent limits.

A reservation cannot be accepted or does not provide expected capacity

Review reservations throughout the parent-child hierarchy and check available unreserved capacity at the relevant levels. Aggregate reservations may exceed parent or root capacity. For a nested pool, determine whether expandable reservation is disabled when the design requires capacity from ancestors.

A child pool cannot satisfy its reservation

Inspect the parent's reservation, limit, and available allocation. Check whether expandable reservation is enabled. If it is disabled, the child must satisfy the requirement locally within the parent allocation. If it is enabled, verify that ancestors have unused reservable capacity and no restrictive limits block the request.

Lower-priority workloads use more resources than expected

Measure actual demand from all sibling pools. Lower-share workloads can use more capacity when higher-share workloads are idle or not requesting their potential allocation. Explain the result using relative weights and active demand; shares are not fixed allocations.

Exam-relevant distinctions

Shares are relative weights, not guaranteed CPU or memory amounts.
Shares matter primarily during contention among competing siblings.
A limit is a maximum and can throttle a pool even when the host has spare capacity.
A reservation is a minimum guaranteed entitlement that requires successful capacity admission.
A reservation is set aside for possible use; it is not necessarily continuously consumed.
Expandable reservation lets a child seek reservation capacity from its parent or ancestors when local capacity is insufficient.
Expandable reservation does not permit general use beyond a configured limit.
CPU and memory attributes are independent. A CPU setting does not automatically change the corresponding memory behavior.
Parent limits and reservations constrain what child pools can effectively receive.

Summary

Resource pool attributes provide four different controls. Shares establish relative priority during contention. Reservations protect minimum CPU or physical memory capacity after admission. Limits impose maximum consumption and can create bottlenecks even on an otherwise idle host. Expandable reservation controls whether a child can obtain reservation support from higher levels of the resource hierarchy.

Effective design starts with the hierarchy: identify the root, parent, child, sibling, and VM relationships; evaluate CPU and memory separately; account for aggregate reservations and future growth; then validate the result through monitoring and controlled testing.