VMware ESXi and vSphere Cluster Management

VMware vSphere Resource Pools Explained

Learn how VMware vSphere resource pools organize CPU and memory allocation with shares, reservations, limits, hierarchy, and practical design examples.

A VMware vSphere resource pool is an inventory object that groups virtual machines and, optionally, child resource pools under a shared CPU and memory allocation policy. Instead of configuring the same priority or capacity rule on every virtual machine, an administrator can apply the policy to the pool.

A resource pool does not create additional physical CPU or memory. It partitions and prioritizes capacity already available from its parent: an ESXi host, a DRS cluster, or another resource pool. Its settings matter most during resource contention, which occurs when concurrent workload demand exceeds available CPU or memory.

What a Resource Pool Does

Resource pools provide a collective way to control access to compute capacity. They are useful when several virtual machines share a business purpose, service class, department, tenant, or operational priority.

• Group production, development, test, or lab virtual machines.
• Give one workload group higher relative priority during contention.
• Protect a workload group with a CPU or memory reservation.
• Place a deliberate maximum on a lower-priority group with a limit.
• Simplify administration by applying common settings to many virtual machines.

Resource allocation is the scheduling and distribution of CPU and memory capacity among pools and virtual machines. The effective result depends on the complete hierarchy, sibling demand, VM-level settings, and currently available host or cluster capacity.

Where Resource Pools Exist

A resource pool can be created beneath a standalone ESXi host or beneath a DRS cluster. An ESXi host is the physical virtualization host that supplies CPU and memory to virtual machines. A DRS cluster uses vSphere Distributed Resource Scheduler to manage and balance workload resource use across multiple hosts.

• Standalone host: The pool partitions the CPU and memory resources available from that host.
• DRS cluster: The pool uses the cluster's aggregate resource capacity, while DRS helps place and balance workloads across hosts.

Cluster-wide resource management depends on DRS availability and the cluster's aggregate capacity. A resource pool does not turn separate, non-clustered hosts into one shared resource domain.

Folders organize inventory objects such as virtual machines and pools, but they do not allocate CPU or memory. Tags and naming conventions classify objects with metadata; they also do not change scheduling behavior.

Resource Pool Hierarchy

Every ESXi host and DRS cluster has an implicit root resource pool. This is the hidden top-level pool representing the resources available from that host or cluster. Administrator-created pools are children of the root pool or of another resource pool.

A parent resource pool is the host, cluster, or pool from which a child receives its available capacity. A child resource pool is nested beneath that parent. Virtual machines can be placed directly in a pool, and pools can contain other pools.

For example:

DRS Cluster
└── Root Resource Pool
    ├── Production
    │   ├── ERP01
    │   └── Web01
    └── Test
        ├── QA01
        └── Lab01

A child pool competes for and receives resources within the boundary established by its parent. A restrictive parent limit can constrain every child below it. A parent reservation can protect capacity for the branch, while child reservations divide or consume that protected capacity. Nested pools should therefore be shallow and easy to explain unless there is a clear policy reason for additional levels.

CPU and Memory Controls

CPU and memory settings are configured separately. A workload may require high CPU priority but little reserved memory, or the opposite. The main controls for both resource types are shares, reservations, and limits.

Shares and Relative Priority

CPU shares are relative CPU priorities used to distribute CPU under contention. Memory shares work similarly for memory. Shares do not reserve resources and do not guarantee a specific CPU or memory amount.

Only the ratio between competing sibling pools is meaningful. Suppose Production and Test are siblings with share values of 2000 and 1000. If both demand scarce resources and no other policy dominates the result, Production has a relative entitlement of approximately two parts to Test's one part. This does not mean Production permanently owns two-thirds of the host or cluster.

Contested capacity: 3000 CPU units
Production shares: 2000
Test shares:       1000
Relative result:   Production receives more contested capacity than Test

If enough unused capacity exists, both groups can receive what they request and the higher share produces no visible advantage. Shares are evaluated within the relevant parent scope, so comparing a Production pool under one branch with an unrelated pool elsewhere is not meaningful.

Depending on the vSphere configuration and version, share policies may use fixed share values or scalable shares. Scalable shares can adjust according to workload composition. Confirm the selected policy's behavior before relying on a share ratio for capacity planning.

Reservations

A reservation is a guaranteed minimum amount of CPU or memory capacity for a pool, subject to the capacity available from its parent and to admission control. Admission control is the capacity check that determines whether requested reservations can be supported.

A pool reservation protects a minimum allocation for the pool's workloads. It does not guarantee that every VM in the pool can always consume any amount it requests. Child-pool and VM reservations also consume capacity within the parent hierarchy. A parent reservation can protect capacity for a branch, while child reservations specify how that branch's capacity is committed further down.

Reservations reduce the unreserved capacity available to sibling pools. If reservations are larger than the host or cluster can support, a VM may not power on or a new reservation may not be admitted. Review reservations carefully in clusters whose hosts, HA requirements, or workloads change over time.

Limits

A limit is the maximum CPU or memory amount a resource pool may consume. The limit remains effective even when the parent has idle capacity. An unlimited setting permits use up to the capacity available through the parent and current scheduling conditions.

Limits are appropriate when a deliberate consumption ceiling is required, such as preventing a lab environment from exceeding an approved allocation. An arbitrary limit can throttle workloads and produce poor performance while host or cluster graphs appear to show unused resources. Always compare observed usage with the pool's configured limit before increasing other resources.

How Policies Interact Through the Hierarchy

Parent settings establish the capacity and policy boundary for child pools. A child cannot obtain more capacity than its parent can make available, and a parent limit can constrain all descendants. Child shares determine relative access within the capacity granted by the parent, not across the entire host or cluster.

VM-level CPU and memory settings coexist with pool-level settings. A VM's own shares, reservation, and limit can therefore affect its behavior inside the pool. When diagnosing scheduling behavior, inspect the VM, its containing pool, every parent pool, sibling demand, and the current host or cluster capacity.

Common Use Cases

• Production versus test: Place business-critical VMs in Production and noncritical VMs in Test. Give Production higher shares so it receives preferential access during contention.
• Application tiers: Separate database, application, and web workloads when each service class needs a distinct policy.
• Business units or tenants: Group workloads by department, project, or tenant and apply documented capacity rules.
• Critical workload protection: Use an appropriately sized reservation for a critical application group after confirming sufficient parent capacity.
• Consumption control: Apply a deliberate limit to a lab or low-priority group when unrestricted consumption is not acceptable.
• Simplified administration: Apply common resource settings to a group instead of editing each VM independently.

Practical Configuration Workflow

1. Select the standalone ESXi host, DRS cluster, or existing parent resource pool in the vSphere Client.
2. Create a new resource pool.
3. Choose a meaningful name that describes the business purpose or workload policy, such as Production or Engineering-Development.
4. Configure CPU shares, CPU reservation, and CPU limit.
5. Configure memory shares, memory reservation, and memory limit.
6. Place existing or newly created virtual machines in the pool.
7. Review the resulting tree and confirm that parent settings can support the intended child policies.
8. Test behavior under realistic contention and document the expected outcome.

Do not treat example values as universal recommendations. Size reservations and limits against actual host or cluster capacity, VM demand, HA planning, and business requirements.

PowerCLI Concepts

PowerCLI can create, inspect, modify, and populate resource pools. Parameter names and supported units can vary by PowerCLI version, so check the installed module's help before using a script in production.

# Inspect available resource pools
Get-ResourcePool

# Review the parameters supported by your installed version
Get-Help New-ResourcePool -Full
Get-Help Set-ResourcePool -Full

# Create a pool; use version-appropriate CPU and memory parameters
New-ResourcePool -Name "Production" -Location $parent

# Inspect a specific pool
Get-ResourcePool -Name "Production"

# Change shares, reservations, or limits with parameters supported by your version
Set-ResourcePool -ResourcePool $productionPool

# Move a VM into the pool
Move-VM -VM "ERP01" -Destination $productionPool

# Verify VM placement
Get-VM -Name "ERP01" | Select-Object Name, ResourcePool

For automation, specify units explicitly where the cmdlet supports them, distinguish CPU from memory parameters, and validate the resulting hierarchy after changes. Never embed capacity values without first measuring the target host or cluster.

Design Guidance and Cautions

• Use a resource pool only when it expresses a real CPU or memory policy.
• Use folders, tags, or naming conventions for organization without allocation requirements.
• Keep hierarchies shallow and understandable unless nested policies are clearly required.
• Avoid arbitrary limits; they can create bottlenecks unrelated to actual physical capacity.
• Size reservations carefully, especially in HA-enabled or frequently changing clusters.
• Document each pool's business purpose, settings, intended workloads, and expected contention behavior.
• Review sibling demand and the full parent-child tree after changes.
• Validate policies under realistic contention rather than assuming shares affect normal, noncontended operation.

Troubleshooting Resource Pool Behavior

Higher production shares show no apparent benefit

• Confirm that CPU or memory contention actually exists.
• Check whether the competing workloads are siblings within the same relevant parent scope.
• Review the entire hierarchy for a restrictive reservation or limit.
• Compare sibling share settings with actual workload demand.
• Check limits at both pool and VM levels.

Shares do not make a difference when all workloads can obtain the capacity they request. They also cannot override a more restrictive limit or a boundary elsewhere in the hierarchy.

A VM cannot power on or a reservation cannot be admitted

• Review reservations at the VM, child-pool, parent-pool, host, and cluster levels.
• Check current available CPU and memory capacity.
• Look for existing reservations that consume the needed unreserved capacity.
• Consider whether host availability or cluster capacity has changed since the policy was designed.
• Reduce or redesign reservations only after validating the requirements of critical workloads.

A VM group performs poorly while resources appear idle

• Inspect the containing pool's CPU and memory limits.
• Inspect limits on all parent pools.
• Compare observed usage with the configured cap.
• Investigate storage, network, guest operating system, and application metrics before attributing the problem solely to CPU or memory scheduling.

Nested pools behave unexpectedly

• Draw the complete resource pool tree.
• Inspect settings at every hierarchy level.
• Remember that shares are relative to siblings, not global across the inventory.
• Confirm that child reservations and limits fit within the parent policy.
• Simplify the hierarchy if its intended allocation cannot be explained clearly.

Resource Pools Versus Organizational Alternatives

Summary

Resource pools partition and prioritize existing CPU and memory capacity beneath an ESXi host or DRS cluster. The root resource pool is the implicit top of the hierarchy; administrator-created pools and virtual machines consume resources below it. Shares provide relative priority during contention, reservations protect minimum capacity subject to admission control, and limits impose maximum consumption even when idle capacity exists.

Design pools around clear operational policies, keep nesting understandable, account for VM-level settings, and validate behavior under realistic contention. For a concise reference to this topic, see Resource Pools Explained.