VMware ESXi and vSphere Cluster Management

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

Learn how VMware ESXi resource pools allocate CPU and memory using shares, limits, reservations, and expandable reservations, with configuration and troubleshooting guidance.

VMware ESXi resource pools organize virtual machines and nested pools into a hierarchy for allocating CPU and memory. Their settings control priority, minimum capacity, and maximum consumption when workloads compete for resources.

A resource pool does not add CPU or memory to an ESXi host or cluster. It governs access to the capacity that already exists. The effect of its settings is most visible when resource demand exceeds available capacity.

What Is a VMware Resource Pool?

A resource pool is a logical container that allocates CPU and memory among virtual machines and child resource pools. A host or cluster has a top-level root resource pool. Administrators can create child pools beneath it, and virtual machines can be placed directly in a pool or in a nested child pool.

The parent-child relationship is important:

The root resource pool is the top-level allocation container associated with an ESXi host or cluster.
A parent resource pool supplies the allocation context and capacity for its children.
A child resource pool inherits the constraints of its parent hierarchy.
Virtual machines compete with sibling virtual machines or pools under the same parent.

This hierarchy supports meaningful boundaries such as production and development, departments, tenants, or service classes. It does not reserve an extra hardware supply. All allocations ultimately come from the host or cluster.

The Four Resource Pool Attributes

CPU and memory are configured independently. Each resource type has four important controls:

Shares: relative priority when sibling objects contend for a resource.
Limit: the maximum CPU or memory the pool may consume.
Reservation: a minimum capacity commitment used during admission control and contention.
Expandable reservation: a pool-specific option that permits descendant reservation requests to use eligible capacity from the parent hierarchy.

Shares are primarily a priority control. Reservations provide guaranteed minimum capacity, subject to parent capacity. Limits impose a maximum. Expandable reservations affect how reservation requirements move through the hierarchy.

Attribute	Primary purpose	Applies during contention	Provides guaranteed minimum	Enforces maximum	Scope and hierarchy behavior	Common risk
Shares	Relative priority	Yes	No	No	Compared with sibling objects under the same parent	Assuming shares are a fixed percentage
Limit	Maximum consumption	Whenever the ceiling is reached	No	Yes	Parent limits constrain all descendants	Artificial throttling
Reservation	Minimum committed capacity	Protects capacity during contention	Yes, if parent capacity supports it	No	Child requirements draw from parent capacity	Over-reserving capacity
Expandable reservation	Allow descendant reservations to use ancestor capacity	During reservation admission	Indirectly	No	Can propagate requests upward through eligible ancestors	Weaker isolation between sibling pools

Shares: Relative Priority During Contention

Shares are relative weights used to distribute constrained CPU or memory capacity. They do not reserve resources and do not cap consumption. When there is no contention, a pool with ordinary shares may use available capacity without receiving a visible benefit from a higher share value.

Shares are compared with sibling objects under the same parent. They are not an absolute percentage of host capacity. A pool with twice as many shares as a sibling is generally entitled to twice that sibling's share of the contested resource, assuming comparable demand and no reservations or limits that change the result.

Common share levels include Low, Normal, and High. vSphere also permits custom share values where available. Custom values are useful when an organization needs an explicit ratio, but the ratio is meaningful only among the relevant siblings.

Share example

Production and Development are sibling pools with equal CPU demand. Production has 4,000 shares and Development has 1,000 shares. During CPU contention, their share weights are 4:1. If the schedulable capacity available to these competing pools is 5,000 MHz, the proportional result is approximately 4,000 MHz for Production and 1,000 MHz for Development, before other hierarchy, reservation, and limit effects are considered.

This is not a permanent allocation. If Development is idle, Production can use more capacity. If Production is idle, Development can use available capacity. Shares matter when sibling objects simultaneously demand the same constrained resource.

Resource-pool shares versus VM shares

VM-level shares govern competition among objects at the VM's allocation level. Resource-pool shares govern competition among sibling pools and other sibling objects. The hierarchy is evaluated together: a VM in a high-share child pool can receive stronger effective priority than a VM in a low-share pool, but a VM-level limit or a parent limit can still restrict it.

Increasing shares cannot override a hard limit. Shares also cannot make a reservation. If increasing shares has no effect, check for contention, sibling relationships, limits, and non-CPU or non-memory bottlenecks.

Limits: A Hard Maximum

A limit is the maximum CPU or memory amount a resource pool may consume. CPU limits are commonly expressed in MHz. Memory limits are commonly expressed in MB or equivalent units shown by the vSphere interface.

A limit can restrict workloads even when the host has unused physical capacity. For example, a test pool with a 2,000 MHz CPU limit cannot consume more than that configured ceiling merely because the host has additional idle CPU.

Limits can be appropriate for a noncritical workload group, a tenant with a defined maximum, or a test environment that must not consume excessive capacity. They should be deliberate. An unnecessarily low limit creates an artificial bottleneck and can make a workload appear poorly sized.

A child VM or child pool may also have its own limit. The effective maximum is constrained by every applicable parent limit and by the object's own limit. A parent limit therefore acts as a ceiling for all descendants. A high share value cannot bypass that ceiling.

Reservations: Guaranteed Minimum Capacity

A reservation is a minimum CPU or memory capacity commitment for a resource pool, VM, or other allocation object. It is subject to the capacity available from the parent hierarchy. A reservation is not a permanent allocation that must be continuously consumed; it is an admission-control commitment that protects capacity when demand rises.

When a pool has a reservation, that committed capacity reduces the unreserved capacity available for sibling objects. A child pool or VM reservation must be supportable by its parent. This is why reservations require capacity planning rather than being assigned solely because a workload currently has high utilization.

Pool reservations and VM reservations

A pool reservation protects a minimum for a group of workloads. A VM reservation protects a minimum for one virtual machine. Both can be relevant: a critical service pool may reserve group capacity, while a particularly important VM may have an additional reservation. The resulting commitments must fit within the parent hierarchy.

During contention, a supported reservation helps the reserved object obtain its committed amount before unreserved capacity is distributed according to shares. It does not guarantee performance above the reserved amount. Additional demand remains subject to limits, contention, and the priorities of other objects.

Over-reserving is a capacity-planning risk. Excessive reservations can prevent new workloads from being admitted and leave capacity committed to workloads that do not use it.

Expandable Reservations

An expandable reservation is a resource-pool setting that allows a pool to seek additional reserved capacity from its parent and higher ancestors when its own reservation is insufficient for a descendant request.

Expansion is triggered when child reservation requirements exceed the capacity available from the pool's existing reservation. If expansion is enabled on the applicable hierarchy and ancestors have eligible capacity, the request can consume part of the parent's available reservation. The request may propagate upward through multiple ancestors where policy and capacity permit.

Enabled versus disabled

With expansion disabled, a VM or child-pool reservation request can fail when the immediate pool cannot satisfy it, even if capacity might exist higher in the hierarchy.
With expansion enabled, the parent can lend part of its available reservation to satisfy descendant requirements, provided the ancestor hierarchy supports the request.

Expansion improves flexibility but can weaken strict isolation between sibling pools. One child can consume eligible parent capacity that another sibling might otherwise use. Enable it when descendant reservations should be allowed to draw from ancestors, and disable it when the parent is intended to be a strict capacity boundary.

How the Attributes Interact

Use this order of reasoning when analyzing a resource allocation design:

Verify that reservations can pass admission control through the parent hierarchy.
Check limits on the VM, pool, and every parent pool.
Assess shares only after confirming that sibling objects are simultaneously demanding the resource.

Reservations establish supported minimum commitments. Limits establish maximum consumption. Shares distribute the remaining contested capacity by relative priority. A parent limit constrains every descendant, and a child reservation draws from parent resources. Expandable reservation settings determine whether a child can use eligible capacity from higher ancestors.

Scenario	Shares effect	Limit effect	Reservation effect	Expandable reservation effect
No contention	Usually little visible effect; idle capacity can be used	Still enforces a ceiling	Capacity remains committed even if unused	Usually no visible effect
Sibling CPU contention	Distributes contested capacity by relative weight	Caps each pool's maximum	Protects supported minimums first	Does not directly distribute runtime capacity
Sibling memory contention	Distributes constrained memory by relative weight	Caps memory consumption	Protects supported minimums	Does not replace admission control
New VM reservation request	Does not make the request admissible	May prevent the required allocation	Must fit within parent commitments	May allow eligible capacity to be obtained from ancestors
Parent capacity insufficient	Cannot solve the shortage	May impose an additional restriction	Request may be rejected	Expansion still fails if ancestors lack eligible capacity
Unused host capacity with a configured limit	Cannot exceed the limit	Creates a hard ceiling	Does not remove the ceiling	Does not remove the ceiling

CPU and Memory Configuration Units

Resource type	Shares	Reservation unit	Limit unit	Administrative note
CPU	Relative values such as Low, Normal, High, or custom shares	MHz	MHz	Interpret values in relation to the host or cluster's schedulable CPU capacity and hierarchy
Memory	Relative values such as Low, Normal, High, or custom shares	MB or equivalent vSphere interface units	MB or equivalent vSphere interface units	Account for physical memory, overcommitment, and reclamation behavior

Configuration Workflow in the vSphere Client

Select the ESXi host or cluster inventory object and locate the resource pool in the resource hierarchy.
Select the existing pool or create a new resource pool at the intended parent level.
Open the resource-pool edit settings or resource allocation interface.
Review and configure CPU shares, reservation, and limit.
Review and configure memory shares, reservation, and limit.
Enable or disable expandable reservation according to the hierarchy and reservation policy.
Before saving, review the parent pool, current reservations, limits, and available capacity.
After saving, verify the pool hierarchy, effective capacity, VM placement, and resource usage during representative load.

Document the parent pool, intended workloads, expected demand, and reason for every nondefault reservation or limit. This makes later troubleshooting and capacity reviews much easier.

PowerCLI inspection and administration

Get-ResourcePool
Get-ResourcePool | Select-Object Name, Parent, VM
Get-VM | Select-Object Name, ResourcePool
Get-Help Get-ResourcePool -Full
Get-Help New-ResourcePool -Full
Get-Help Set-ResourcePool -Full

Use Get-ResourcePool to inspect pools and parent-child relationships. Use New-ResourcePool to create a planned pool and Set-ResourcePool to modify allocation settings. Use Get-VM together with Get-ResourcePool to verify workload placement. Exact parameter names and availability can vary with installed PowerCLI and vSphere versions, so use Get-Help before applying changes.

Monitoring and Operational Validation

Review configured allocation values alongside actual usage and demand. Useful inputs include CPU and memory usage, demand, contention indicators, CPU ready time or other scheduling pressure, reservation utilization, and available parent capacity.

Distinguishing common constraints

Pool limit: usage or demand approaches the same configured ceiling even while the host appears to have unused capacity. Inspect VM, pool, and parent limits.
General contention: multiple siblings have concurrent demand and constrained capacity. Compare share weights, reservations, and contention metrics.
Shares not relevant: sibling pools are not simultaneously demanding the resource, or the competing objects are not siblings under the same parent.
Reservation pressure: a new reserved workload cannot be admitted, or available unreserved parent capacity is low. Review reservation utilization before deployment.

When increasing shares, first confirm concurrent demand among the correct sibling objects. If demand is absent, shares will not produce a noticeable change. Also investigate storage, networking, guest operating system, and application bottlenecks before attributing poor performance to pool allocation.

Design Guidance

Use shares to express relative business priority, not to promise a fixed minimum.
Use reservations only for workloads that require a defined minimum service level and after analyzing capacity.
Use limits sparingly and deliberately because they can create artificial bottlenecks.
Use expandable reservations when descendant reservation requests should be able to consume eligible capacity from ancestors.
Avoid deeply nested or poorly documented pool structures.
Base pools on meaningful operational boundaries such as production tiers, departments, tenants, or service classes.
Review the effect of a new reservation on siblings and on future admission capacity.

Troubleshooting Resource Pool Problems

Reservation change or VM power-on is rejected

Trace the VM's pool hierarchy to the root. Compare the requested reservation with available capacity at each level. Check whether expandable reservation is enabled on the applicable pools, then review parent reservations, ancestor capacity, and parent limits. Common causes include insufficient child reservation capacity, disabled expansion, insufficient unreserved ancestor capacity, or a parent limit.

Performance is poor although the host appears to have unused resources

Inspect limits on the VM, its pool, and all parent pools. Compare the configured limits with usage and demand. Remove or increase an unnecessary limit only after evaluating its effect on other workloads. If limits are not responsible, investigate whether the observed bottleneck is storage, network, guest, application, or another resource.

Increasing shares does not improve performance

Confirm concurrent CPU or memory demand and contention among sibling objects. Check that the competing objects are actually under the same parent. Inspect limits before changing shares again. A share increase has little effect without contention and cannot bypass a limit.

Lower-priority workloads consume more than expected

Higher-priority pools may not currently be demanding capacity. Shares are contention-based weights, not fixed allocations. Unused capacity can therefore be consumed by another pool. Add a deliberate limit only when a hard cap is an actual business requirement.

Exam-Relevant Notes

Shares are relative and matter primarily during contention.
A reservation is a minimum commitment, not a permanent requirement to consume resources.
A limit is a maximum and can throttle a workload despite unused host capacity.
Child reservations must be supportable by the parent hierarchy.
Expandable reservation allows descendant requests to draw eligible capacity from parent or ancestor reservations.
A high share value cannot override a limit.
A resource pool organizes and prioritizes existing capacity; it does not create hardware capacity.

For related capacity and admission concepts, review Admission Control Explained and Admission Control Policy. For inventory and permissions context, see Add ESXi Host to vCenter Server Inventory and Assign Permissions.