VMware ESXi and vSphere Cluster Management
How VMware vSphere Resource Pools Work
Learn how vSphere resource pools allocate CPU and memory with shares, reservations, limits, hierarchy, and expandable reservations.
A VMware vSphere resource pool is a logical container for controlling how virtual machines receive CPU and memory from an ESXi host or cluster. A pool can represent a team, application, environment, or service tier.
A resource pool does not create additional physical CPU or memory. It controls access to the capacity supplied by its parent. The parent might be a standalone ESXi host, a cluster, or another resource pool.
Why use resource pools?
Resource pools are useful when workloads need intentional prioritization. For example, an organization might create separate pools for production, development, and testing. A production pool could receive a reservation and a higher priority than a development pool.
Use a pool when you need to control resource entitlement or capacity. If you only need to organize inventory by department, project, or environment, a vSphere folder is usually more appropriate. Folders organize objects; resource pools influence resource allocation.
- Teams: allocate capacity to Engineering, Finance, or Operations.
- Applications: group all VMs supporting a business service.
- Environments: separate production, staging, and test workloads.
- Service tiers: prioritize critical workloads over lower-priority workloads.
Resource pool hierarchy
At the top of an ESXi host or cluster is the root resource pool. It represents the resources available from that host or cluster. Administrators normally place child resource pools and virtual machines beneath this root.
A pool beneath another pool is a child resource pool. The pool above it is its parent resource pool. Child pools compete with their sibling pools for resources supplied by the parent.
Virtual machines can be placed directly in a pool. Those VMs compete with one another for the resources made available to that pool. If a child pool contains further pools, each level performs its own allocation decision.
- The root or parent allocates resources among its child pools and directly placed VMs.
- A child pool allocates its received resources among its own child pools and VMs.
- VMs inside the same pool compete only within that pool's available allocation.
This creates a two-stage, and sometimes multi-stage, process. A VM's effective entitlement depends on its immediate siblings and on the allocation received by every ancestor pool.
CPU and memory resource settings
CPU and memory are controlled separately. A pool can have CPU shares, a CPU reservation, and a CPU limit, while having different settings for memory. A CPU setting does not automatically change memory allocation.
Shares
Shares are relative weights used when competing workloads need more resources than the parent can provide. Shares do not reserve capacity. When enough CPU or memory is available, shares generally have no practical effect on consumption.
Shares are compared among objects with the same immediate parent. A VM's shares are not automatically a percentage of the entire ESXi host. For a VM inside Engineering, its shares are compared with sibling VMs inside Engineering, not with every VM on the host.
Reservations
A reservation is a guaranteed minimum amount of CPU or memory for a pool or VM, provided that the required backing capacity exists and admission control permits placement or power-on.
A resource-pool reservation is different from a VM reservation. A pool reservation establishes minimum backing for the pool as a whole. A VM reservation establishes a minimum for that particular VM. Reservations beneath a pool must be supportable by the parent hierarchy.
Reservations reduce unreserved capacity available to siblings. Excessive reservations can therefore prevent a new VM from powering on or prevent a VM or pool from being placed, even when the configured totals appear reasonable at another level.
Limits
A limit is a maximum CPU or memory consumption ceiling. Unlike shares, a limit can restrict a workload even when the host has unused capacity.
A pool-level limit applies to the aggregate resource use of workloads in that pool. If an Engineering pool has a 4,000 MHz CPU limit, the combined CPU consumption of its workloads cannot exceed that ceiling. A VM can therefore experience CPU throttling while overall ESXi host utilization remains low.
Restrictive limits are an operational risk. They can make a VM slow, increase CPU ready time, or cause memory pressure inside a pool that is not reflected by total host utilization.
How shares produce proportional allocation
Suppose two sibling pools compete for a constrained parent resource. The parent compares their shares and distributes the available entitlement proportionally. If Pool A has 2,000 shares and Pool B has 1,000 shares, Pool A has twice the relative entitlement of Pool B during that contention.
The same principle applies inside a pool. If two sibling VMs have 2,000 and 1,000 shares, the first VM is entitled to about two-thirds and the second to about one-third of the pool's distributable capacity when they are both demanding resources.
The allocation process can be summarized as follows:
- The parent divides constrained resources among sibling pools according to their reservations, limits, and relative shares.
- Each child pool receives an allocation subject to its own limit and reservation.
- The child pool divides its available allocation among sibling VMs according to their shares and VM-level settings.
Consequently, a VM's shares do not mean “this percentage of the host.” They mean “this relative portion of the resources available to my immediate competition.”
Expandable reservations
An expandable reservation allows a resource pool to obtain additional reserved capacity from its parent when the reservations required by workloads below the pool exceed the pool's own reservation.
For example, a child pool might have a 1,000 MHz reservation while VMs beneath it require more reserved CPU. With expandable reservation enabled, the pool can request additional backing from its parent if the parent has available capacity.
This setting does not override a parent limit and does not create CPU or memory that does not exist. If the parent lacks available unreserved capacity, or if an ancestor limit prevents expansion, the additional reservation cannot be satisfied.
Expandable reservations have a trade-off. They can help satisfy VM reservations, but the extra backing may consume capacity that sibling pools expected to use. Enable the setting only when the parent-level policy allows that behavior.
Worked hierarchy example
Consider a standalone ESXi host whose root resource pool represents 12,000 MHz of CPU capacity and 4 GB of memory. Create an Engineering child pool with these CPU settings:
- CPU reservation: 1,000 MHz
- CPU limit: 4,000 MHz
- Expandable reservation: enabled
Place two VMs inside Engineering:
- Engineering test VM: 1,000 CPU shares
- Engineering production VM: 2,000 CPU shares
The two VMs have 3,000 total shares. During contention inside Engineering, the production VM has approximately 2,000 / 3,000, or two-thirds, of the CPU capacity available to the two VMs. The test VM has approximately 1,000 / 3,000, or one-third.
Those percentages apply to the Engineering allocation, not directly to the full 12,000 MHz host. If Engineering receives 3,000 MHz from its parent, the proportional result is approximately 2,000 MHz for the production VM and 1,000 MHz for the test VM, subject to reservations, limits, demand, and scheduler behavior.
The 1,000 MHz Engineering reservation is different from this proportional result. The reservation is guaranteed backing for the pool. Shares influence allocation above the guaranteed amount when contention exists. The 4,000 MHz limit remains a hard ceiling for the aggregate Engineering workload, even if the host has spare CPU.
Adding a sibling pool
Now add another child pool beneath the same root. Give that sibling pool 1,000 CPU shares. Engineering must compete with the new sibling at the root level. Engineering's available parent-level entitlement can decrease, depending on Engineering's shares relative to the sibling's shares and on reservations, limits, and demand.
After the root makes an allocation to Engineering, the two Engineering VMs still divide only Engineering's received allocation. The production VM remains approximately two-thirds of the Engineering VM-level share allocation, and the test VM remains approximately one-third. Root-level competition changes the size of the Engineering allocation; it does not change the ratio between the two VMs.
Contention scenarios
No host contention
When demand is below available capacity, workloads can generally consume what they need regardless of relative shares. A share setting becomes important when the relevant parent resource is constrained. A limit can still restrict consumption in this situation.
Parent-level contention
When sibling pools demand more CPU or memory than the parent can provide, the parent allocates resources according to pool reservations, limits, and shares. A pool may receive less than an administrator expects if another sibling has a reservation, a stronger relative share setting, or greater eligible demand.
Child-level contention
When several VMs in one pool compete for that pool's allocation, their VM-level shares determine their relative entitlement. Their shares are not compared with VMs in unrelated pools.
Limit-created contention
A pool limit can create an internal bottleneck. For example, Engineering may have access to a host with more than 4,000 MHz available, but a 4,000 MHz pool limit prevents its combined workloads from using the excess. The resulting contention is caused by configuration rather than physical host shortage.
CPU and memory symptoms differ
CPU contention can appear as high CPU ready time, scheduling delays, and lower CPU usage than the VM demands. Memory contention can involve memory reclamation mechanisms such as ballooning, compression, and swapping. Evaluate CPU and memory independently; a host can have CPU contention without memory contention, or the reverse.
Administration with the vSphere Client
In the vSphere Client, an administrator can create a resource pool under an ESXi host or cluster, configure CPU and memory shares, reservations, and limits, and enable or disable expandable reservation. VMs can then be moved into the intended pool.
- Select the host or cluster and create a resource pool.
- Give the pool a purpose-based name, such as Production Applications or Engineering Test.
- Configure CPU and memory settings separately.
- Choose whether expandable reservation is appropriate for the parent policy.
- Move the intended VMs into the pool.
- Review the inventory hierarchy and confirm parent, child, and sibling relationships.
Review the complete hierarchy after changes. A setting that looks reasonable on one pool may have a very different effect when an ancestor has a restrictive limit or when several sibling pools have large reservations.
PowerCLI concepts
PowerCLI can be used to create and inspect pools, retrieve VM allocation settings, and audit nested configurations. Common command names include:
Get-ResourcePool
New-ResourcePool
Set-ResourcePool
Get-VM
Get-VMResourceConfiguration
Set-VMResourceConfigurationUse these commands to inspect pool relationships, compare sibling settings, identify configured limits, and review CPU and memory allocation objects for VMs. Test changes in a controlled environment and verify the resulting hierarchy before applying policy to production workloads.
Design and monitoring guidance
- Use resource pools for intentional workload prioritization, not as a default replacement for inventory folders.
- Document each pool's purpose, parent, reservations, limits, expandable-reservation setting, and sibling share relationships.
- Minimize nested pools unless each level represents a clear allocation policy.
- Avoid arbitrary limits. Every limit should have a documented operational reason.
- Avoid oversized reservations that consume capacity without a demonstrated workload requirement.
- Monitor pool-level performance as well as VM-level performance.
- Compare demand, usage, reservation, limit, and entitlement rather than relying on host-wide utilization alone.
Troubleshooting resource-pool behavior
Exam-relevant summary
- Shares are relative priorities, not reservations and not fixed host percentages.
- Reservations establish minimum backing subject to capacity and admission control.
- Limits cap usage even when unused host resources exist.
- Shares are compared among immediate siblings.
- Allocation occurs first from parent to child pool and then from child pool to its VMs.
- A pool reservation and a VM reservation are separate settings.
- Expandable reservation can obtain backing from a parent but cannot override parent limits or create capacity.
- CPU and memory allocation must be analyzed separately.
Resource pools work best when their hierarchy expresses a deliberate allocation policy. Start with the business priority, define the parent-child relationships, configure only the reservations and limits that are justified, and validate behavior at both pool and VM levels.