VMware ESXi and vSphere Cluster Management

VMware vSphere Resource Pools Explained

Learn how VMware vSphere resource pools organize CPU and memory, and how shares, reservations, and limits control VM resource access.

What Is a VMware vSphere Resource Pool?

A resource pool is a vSphere inventory object that groups virtual machines and, optionally, child resource pools so you can manage their CPU resources and memory resources as an aggregate. Instead of configuring every VM independently, you can apply an allocation policy to a workload group.

Resource pools partition available compute capacity according to organizational, application, environment, or service-priority requirements. For example, an administrator might create separate pools for production, testing, development, or different departments.

Resource pools are useful when multiple VMs share a policy boundary. A production pool can receive a higher priority than a test pool, or a temporary lab pool can be prevented from consuming more than a defined amount of capacity.

Before working with pools, review basic VMware vSphere administration concepts, including hosts, clusters, virtual machines, and vCenter Server inventory.

Where Resource Pools Exist

You can create resource pools in two main locations:

• Standalone ESXi host: The host supplies the CPU and memory capacity. The pool hierarchy is based on the resources available from that single host.
• DRS-enabled vSphere cluster: The cluster supplies pooled CPU and memory capacity from its hosts. A cluster-level resource pool is managed against the aggregate resources available through the cluster.

The resource source matters when you plan capacity. A host resource pool cannot draw capacity from other hosts. A cluster resource pool is associated with the cluster's pooled compute capacity and is managed within the cluster's resource hierarchy.

Resource pools are separate from storage inventory structures. A datastore or datastore cluster provides storage resources, while a resource pool organizes CPU and memory resources. For related cluster capacity planning, see vSphere admission control.

Understanding the Resource Pool Hierarchy

Resource pools use a parent-child hierarchy. Each ESXi host and each cluster has an implicit root resource pool. You normally do not create this root object; it represents the CPU and memory resources available from the host or cluster.

Child resource pools are subdivisions of their parent. A child pool can contain virtual machines and additional nested pools. Virtual machines can also be placed directly in the root pool rather than inside a child pool.

• Root resource pool: The implicit top-level pool for an ESXi host or cluster.
• Parent resource pool: The pool that supplies resources to a child and defines the child’s immediate competition boundary.
• Child resource pool: A pool created beneath another pool to subdivide its allocated CPU and memory.
• Virtual machine: A workload placed directly in a pool or inside a nested pool.

Allocation rules are evaluated relative to the parent. Child pools compete with their siblings for the resources made available by their parent. A VM inside a child pool is therefore affected by the policies of its own pool and by the policies applied at higher levels of the hierarchy.

The Three Resource Allocation Controls

Each resource pool can have separate CPU and memory settings for shares, reservations, and limits. These controls have different purposes and can be configured independently. A pool might have high CPU shares but normal memory shares, for example.

Shares: Relative Priority During Contention

Shares are relative allocation weights. They express which sibling pool should receive more of a constrained parent resource when demand exceeds available capacity. Shares do not reserve CPU or memory, and they do not create additional physical capacity.

Shares matter when the parent pool has insufficient available resources to satisfy the demand of its children. During normal operation, if enough CPU or memory is available, lower-share workloads may use substantial resources without violating the share policy.

For example, consider two sibling pools:

• Production: 4,000 CPU shares
• Test: 1,000 CPU shares

The relative ratio is 4:1. If both pools demand more CPU than their parent can provide, Production receives roughly four times the constrained allocation of Test, subject to reservations, limits, and each pool's actual demand. This is a relative priority, not an absolute performance guarantee.

Shares are compared with the shares of competing siblings. A value such as 4,000 is not a fixed number of megahertz or gigahertz. Its meaning comes from the other share values at the same hierarchy level.

Reservations: Minimum Capacity

A reservation is a configured minimum amount of CPU or memory intended to be guaranteed for a resource pool. The parent must have enough capacity to support the reservation before it can be applied. Existing reservations in the parent hierarchy can reduce the unreserved capacity available for new reservations and sibling workloads.

A pool reservation establishes capacity for the pool as a whole. How that capacity is distributed internally still depends on the demand and allocation settings of the VMs and child pools inside it. A reservation does not automatically give every member VM its own equal guarantee.

Reservations require careful planning in nested designs. A large department-level reservation may leave too little unreserved capacity for other departments. Reservations should reflect a documented service requirement rather than being used as a general performance setting.

Limits: Maximum Capacity

A limit is the maximum amount of CPU or memory that a resource pool may consume. The limit acts as a deliberate ceiling even when the host or cluster has idle resources outside that pool.

Limits are appropriate when containment or policy enforcement is more important than allowing unrestricted use of available capacity. For example, a temporary lab pool could have a CPU and memory limit so that it cannot grow beyond an approved allocation.

Use limits cautiously. An unnecessarily low limit can make a VM group perform poorly even though the host or cluster appears to have unused capacity. A limit is not the same as a reservation: a reservation establishes a minimum, while a limit restricts the maximum.

How Pools Separate Workload Classes

A common design creates sibling pools under the host or cluster root:

• Production: Business-critical application VMs.
• Test: Nonproduction validation VMs.
• Development: Build and development systems.
• Staging: Workloads preparing for production.

Assigning Production more CPU and memory shares than Test gives Production a larger proportional allocation during contention. When there is no contention, shares alone do not prevent Test VMs from using available resources.

The main administrative benefit is aggregate control. You can move related VMs into one pool and apply a policy once instead of repeatedly configuring each VM. The pool also communicates the intended service boundary to administrators.

Example: Production Versus Test

1. Create sibling pools named Production and Test under the host or cluster root pool.
2. Place business-critical VMs in Production and noncritical test VMs in Test.
3. Assign Production more CPU and memory shares than Test.
4. Monitor demand and contention to confirm that the policy produces the intended result.

If both pools become constrained, Production receives the larger proportional allocation. If the parent has sufficient capacity, both pools can consume resources according to demand.

Example: Departmental Hierarchy

Create top-level pools for Engineering and Finance. Under Engineering, create child pools for Build Systems and Development VMs. The Engineering parent establishes the department's overall resource boundary, while its child pools provide additional prioritization inside that boundary.

Contention-Based Behavior

Resource contention occurs when aggregate CPU or memory demand exceeds the resources available from the relevant parent. Resource pools do not improve physical capacity; they determine how available capacity is allocated.

• Sufficient capacity: Workloads can generally receive the resources they demand, subject to configured limits and other controls. Shares may have little visible effect.
• Contention: Shares influence relative distribution among competing siblings.
• Minimum requirement: Reservations establish intended minimum capacity when the parent can support it.
• Maximum policy: Limits establish ceilings that workloads cannot exceed, even if unused capacity exists elsewhere.

Always evaluate whether the issue is CPU contention, memory contention, a limit, a reservation constraint, or another infrastructure bottleneck. A resource pool policy cannot compensate for insufficient physical host or cluster capacity.

Administration Workflow

1. Select the standalone ESXi host or DRS cluster that will own the resource pool.
2. Create a new resource pool beneath the selected root pool or an existing parent pool.
3. Give the pool a meaningful name that identifies its workload boundary or service class.
4. Configure CPU shares, reservation, and limit.
5. Configure memory shares, reservation, and limit separately.
6. Move the appropriate virtual machines into the pool.
7. Review the hierarchy and monitor utilization, demand, and contention.

On a cluster, first confirm that the cluster design and DRS configuration support the intended placement and capacity behavior. For host and vCenter inventory administration, see adding an ESXi host to vCenter Server inventory.

Resource Pool Design Checklist

• Identify whether the pool is for prioritization, a minimum guarantee, a maximum cap, or a combination.
• Create a pool only when there is a clear workload boundary, distinct service priority, or shared policy requirement.
• Confirm available CPU and memory capacity at the parent level before setting reservations.
• Set shares relative to sibling pools; do not interpret them as standalone capacity values.
• Plan CPU and memory policies separately because demand may differ between the two resources.
• Avoid deeply nested hierarchies that are difficult to explain, monitor, and troubleshoot.
• Avoid excessive reservations that consume unreserved capacity needed by other workloads.
• Avoid limits unless a defined policy requires a hard ceiling.
• Document each pool's purpose, parent location, member workloads, CPU policy, and memory policy.
• Measure demand and contention before and after applying a policy.

Design Scenarios

Practical Configuration Examples

Reservation for a Critical Service Group

1. Create a resource pool for the critical application suite.
2. Confirm that the parent has enough unreserved CPU and memory capacity.
3. Assign a planned reservation based on measured service requirements.
4. Place the service VMs inside the pool.
5. Monitor whether the reservation remains appropriate as the service changes.

The reservation supports minimum-capacity assurance for the pool, but the internal distribution of that capacity depends on child settings and workload demand.

Limit for a Temporary Lab

1. Create a pool for temporary lab VMs.
2. Apply a CPU and memory limit based on the approved lab capacity.
3. Keep production workloads outside the capped pool or in a separately prioritized pool.
4. Review the limit when the lab's workload or purpose changes.

The limit prevents the lab from exceeding its ceiling, but it may throttle lab VMs even when the physical environment has unused resources.

Troubleshooting Resource Pool Behavior

A Test VM Uses Substantial Resources While Production Is Not Busy

Likely cause: Shares are not an always-on cap. They affect relative allocation only when the parent pool experiences contention.

• Check whether the parent host or cluster is actually under CPU or memory contention.
• Review the shares of the sibling pools.
• Check whether a limit was expected but was never configured.

Use shares for contention priority. Add a carefully justified limit only if the lower-priority pool must be capped even when capacity is idle.

A VM Group Performs Poorly Despite Apparent Unused Capacity

Likely cause: The affected pool or one of its parent pools may have a restrictive CPU or memory limit.

• Inspect CPU and memory limits on the affected pool and its parents.
• Trace the VM's complete resource pool hierarchy.
• Compare observed usage with the configured limits.

Raise or remove an unnecessary limit only after verifying the intended policy and its effect on other workloads.

A New Reservation Cannot Be Applied

Likely cause: The parent may not have sufficient unreserved resources to satisfy the requested guarantee.

• Review existing reservations on the parent and sibling pools.
• Confirm available unreserved CPU and memory capacity.
• Check whether nested reservations have consumed parent capacity.

Reduce the requested reservation, free reserved capacity, or redesign the hierarchy according to actual service requirements.

A Critical Workload Does Not Receive the Expected Advantage

Likely cause: Its pool may have the same or fewer shares than competing siblings, or its parent may itself be constrained.

• Compare sibling share values at every relevant hierarchy level.
• Verify that the workload is in the intended pool.
• Check parent-level reservations and limits.
• Confirm that the problem is CPU or memory contention rather than another infrastructure bottleneck.

Adjust relative shares and review the complete parent-child hierarchy instead of changing only VM placement.

Behavior Changes After Moving a VM

Likely cause: The VM inherited a different aggregate policy and now competes with a different set of sibling workloads.

• Compare the old and new parent hierarchies.
• Review shares, reservations, and limits in both locations.
• Identify the workloads competing in each destination pool.

Place the VM in the pool matching its intended service priority and validate policies at all parent levels.

Exam-Relevant Notes

• A resource pool manages CPU and memory, not storage.
• Every ESXi host and cluster has an implicit root resource pool.
• Child pools compete with sibling pools for resources from their parent.
• Shares are relative priorities used primarily during contention; they are not guarantees or caps.
• Reservations establish intended minimum capacity and consume parent capacity.
• Limits establish maximum consumption and can throttle workloads despite idle physical capacity.
• Resource pools manage allocation behavior; they do not add physical CPU or memory.

Summary

VMware vSphere resource pools provide hierarchical, aggregate control over CPU and memory for groups of virtual machines and nested pools. A standalone ESXi host supplies the resources for a host-level hierarchy, while a DRS cluster supplies pooled cluster capacity. Shares determine relative priority during contention, reservations establish minimum capacity when the parent can support it, and limits impose maximum ceilings.

The most reliable designs use simple, documented boundaries that reflect real workload priorities. Monitor demand and contention, use shares for prioritization, reservations for justified minimum requirements, and limits only when a hard cap is intentional.