VMware ESXi and vSphere Cluster Management

Create and Configure a Resource Pool in VMware vSphere

Learn to create vSphere resource pools, configure CPU and memory shares, reservations, limits, and move virtual machines into a pool.

A resource pool is a logical container that controls how CPU and memory are allocated to a group of virtual machines (VMs). You create resource pools in vSphere through vCenter Server, under an ESXi host, cluster, or another resource pool.

Resource pools are useful when several VMs share an allocation policy. Instead of configuring every VM independently, you can place the VMs in a pool and manage their collective priority, guaranteed capacity, and maximum consumption.

What a Resource Pool Is Used For

Common reasons to create a resource pool include separating workloads by:

Department or administrative owner
Application tier, such as web, application, and database servers
Environment, such as production, development, and test
Service importance or business priority
Tenant or customer

For example, a production pool and a development pool can be siblings under the same cluster. Production VMs can receive a higher relative priority during contention, while development VMs remain available when capacity is not constrained.

Understand the Resource Pool Hierarchy

The resource hierarchy describes where capacity comes from and how it is distributed:

A host or cluster is the top-level provider of CPU and memory capacity.
A parent resource pool receives allocatable capacity from that host or cluster.
A child resource pool is nested below a parent pool and receives resources from that parent.
Virtual machines consume resources from the pool that contains them.

A parent distributes its available resources among child pools and VMs. Shares, reservations, and limits are interpreted within the relevant parent scope. A pool with high shares is not automatically entitled to more resources than every object in the entire cluster; its priority is compared primarily with sibling pools or VMs competing under the same parent.

Nested pools can be useful for layered policies, but excessive nesting makes capacity planning and troubleshooting harder. Before creating a child pool, identify which parent supplies its capacity and how its settings interact with sibling pools.

Prerequisites and Planning

Before starting, confirm the following:

You can sign in to vCenter Server and open the Hosts and Clusters inventory view in the vSphere Web Client.
Your account has privileges to create and modify resource pools and to move VMs between inventory locations. If access is denied, review vCenter permissions and the relevant access control roles.
You have selected the correct ESXi host, cluster, or existing parent resource pool.
You understand the host or cluster's available CPU and memory capacity.
You have identified the VMs that belong in the pool and their expected demand.
You know whether the workload needs a reservation, a relative priority, or a deliberate consumption cap.

Plan the pool's purpose, owner, affected VMs, expected workload demand, minimum guaranteed capacity, and likely contention. Reservations should be based on a documented minimum operating requirement, not simply on the VM's maximum configured size.

Create a Resource Pool in the vSphere Web Client

Sign in to vCenter Server.
Open Home, select vCenter, and open Hosts and Clusters.
Select the target ESXi host, cluster, or parent resource pool.
Open the actions menu for the selected object.
Choose New Resource Pool.
Enter a meaningful name that identifies the workload or owner, such as Production, Development, or Critical-App.
Configure the CPU and memory allocation settings.
Review the summary and finish the wizard.

The new pool should appear beneath the selected parent object. The exact labels or menu placement can vary slightly between vSphere versions, but the operation starts in the Hosts and Clusters inventory.

Resource pool configuration fields

Home → vCenter → Hosts and Clusters
Select host, cluster, or parent pool
Actions → New Resource Pool
Name
CPU shares, reservation (MHz), limit (MHz)
Memory shares, reservation (MB), limit (MB)
Expandable reservation

CPU and Memory Resource Settings

CPU settings control processor capacity, while memory settings control physical memory capacity. Each resource type has shares, a reservation, and a limit.

Setting	Purpose	CPU unit or behavior	Memory unit or behavior	Effect during contention	Key caution
Shares	Relative priority	Relative CPU weighting	Relative memory weighting	Higher shares receive a larger portion of constrained capacity compared with siblings	Shares are not a guaranteed amount
Reservation	Guaranteed capacity	Specified in MHz	Specified in MB	Capacity is reserved for the pool when admission requirements are evaluated	Large reservations reduce capacity available elsewhere
Limit	Maximum consumption	Maximum CPU in MHz	Maximum memory in MB	The pool cannot consume beyond the configured cap, even if unused host capacity exists	An unnecessary limit can throttle workloads
Expandable reservation	Allows a child pool to use unused parent capacity	Can obtain unused parent CPU capacity to satisfy its reservation request	Can obtain unused parent memory capacity to satisfy its reservation request	Provides flexibility within the hierarchy	It affects parent-level capacity and must be planned carefully

Shares are relative priority values used when competing workloads experience resource contention. Standard levels are Low, Normal, and High. Custom allows a specific share value.

Shares matter primarily when sibling pools or VMs cannot all receive the resources they request. They do not reserve CPU or memory and do not force a workload to consume resources. If the host has enough capacity, Low and High share settings may produce no visible difference.

For example, if Production and Development are sibling pools and Production has a higher share level, Production receives a larger relative portion of constrained CPU or memory. This preference applies only while the parent has contention.

Reservations

A reservation is a guaranteed amount of capacity. CPU reservations are expressed in MHz, and memory reservations are expressed in MB. Reservations protect a minimum amount for the pool, subject to the capacity available from its parent.

A reservation can affect admission control, which validates whether a requested operation can be satisfied. If a pool or VM reservation cannot be met, a VM might not power on or a resource operation might be rejected. Check the parent pool's unreserved capacity before relying on a reservation.

Limits

A limit is the maximum CPU or memory capacity the pool may consume. CPU limits are expressed in MHz, and memory limits are expressed in MB. A limit is a cap, not a target or a guarantee.

Use limits only when a deliberate budget or isolation policy requires them. A restrictive limit can cause poor performance even when the ESXi host appears to have unused resources, because the pool is prohibited from using that capacity.

Expandable reservations

When an expandable reservation is enabled, a child pool may obtain unused resources from its parent to satisfy its reservation request. This can make a hierarchy more flexible, but it also means the child can draw on capacity that might otherwise appear available to other objects in the parent.

Expandable reservations should be used with a clear understanding of the entire hierarchy. They can help critical workloads obtain their planned capacity, but broad use can make parent-level capacity less predictable.

When to Use Shares, Reservations, and Limits

Allocation control	Best use case	What it guarantees or restricts	Potential downside
Shares	Prioritize workloads only during contention	Relative access to constrained CPU or memory	No absolute guarantee; the effect is invisible when there is no contention
Reservations	Protect a documented minimum requirement for a critical workload	Guaranteed CPU or memory capacity if the parent can satisfy it	Consumes capacity and can prevent VM power-on or other operations
Limits	Enforce an approved maximum consumption budget	Caps the pool's CPU or memory usage	Can throttle VMs even when unused host capacity remains

Resource Pool Design Examples

Pool name	Workload type	Suggested priority approach	Reservation approach	Limit approach
Production	Business and customer-facing VMs	Higher shares than development when contention is expected	Reserve only documented minimum requirements	Normally no limit unless a policy requires one
Development or test	Nonproduction and experimental VMs	Normal or Low shares relative to production	Usually avoid reservations unless a test service needs guaranteed capacity	Use only to enforce a deliberate nonproduction budget
Business-critical application	Application-tier VMs with a defined minimum requirement	High shares among sibling pools	Reserve the tested minimum CPU and memory requirement	Avoid a limit that conflicts with failover or peak demand
Tenant or departmental workload	Workloads owned by a department or tenant	Set shares according to the service agreement	Reserve capacity only when contractually or operationally required	Apply a documented consumption cap when isolation is required

Add Virtual Machines to the Resource Pool

Locate the existing VM in the Hosts and Clusters inventory.
Drag the VM to the target resource pool, or select the equivalent move action.
Review any placement or compatibility confirmation.
Complete the move.
Verify that the VM appears beneath the intended resource pool.

A VM inherits the resource constraints and relative priority of its containing pool. After placement, review the VM's own CPU and memory shares, reservations, and limits. VM-level settings interact with pool-level settings and can explain behavior that is not obvious from the pool configuration alone.

Verify and Monitor the Configuration

After creating the pool and placing VMs in it, verify:

The pool is beneath the intended host, cluster, or parent pool.
The correct VMs appear beneath the pool.
CPU shares, reservation, limit, and expandable reservation are correct.
Memory shares, reservation, and limit are correct.
Reservations fit within the parent hierarchy's available capacity.

Allow the workloads to run under normal conditions, then review vCenter Server resource usage and performance charts for the pool and its VMs. Monitor CPU usage, CPU ready time where relevant, memory consumption, reservation usage, and contention indicators. Reassess the design when VM counts, workload demand, or host capacity changes.

For cluster-level behavior, also understand the relationship between resource pools and vSphere cluster resource management. Admission-control concepts are covered in Admission Control Explained and Admission Control Policy.

Operational Guidance

Document the purpose, owner, affected workloads, and allocation policy for every production pool.
Keep the hierarchy as shallow as possible while still expressing the required policy.
Use reservations selectively for workloads that genuinely require guaranteed capacity.
Avoid limits unless a deliberate cap is required and tested.
Compare shares only among objects in the same parent scope.
Review both pool-level and VM-level settings during performance investigations.
Revisit allocations after adding hosts, changing VM sizes, or changing workload behavior.

Troubleshooting

A VM cannot be powered on after placement

Likely causes include a pool or VM reservation that cannot be satisfied, insufficient unreserved capacity in the parent, or reservations elsewhere in the hierarchy consuming available capacity.

Review CPU and memory reservations at the VM, pool, and parent levels.
Check available capacity and the admission-control message.
Reduce an unnecessary reservation, add capacity, or revise the hierarchy.

A VM performs poorly although the host has unused resources

A CPU or memory limit on the pool or VM may be throttling the workload. Inspect both levels, remove or raise a limit only if it is not intentional, and compare performance charts before and after the change.

A high-priority workload does not receive more resources

There may be no actual contention, so shares have no visible effect. Alternatively, a limit or another bottleneck may be controlling performance. Confirm that contention exists, compare shares among siblings under the same parent, inspect limits, and investigate guest, storage, or network bottlenecks.

The pool cannot be created or edited

Confirm that the selected object is an appropriate parent and that the account has the required inventory and resource-pool privileges. If the operation is still unavailable, ask a vCenter administrator to review the assigned role.

Allocation becomes difficult to predict

Map the parent-child hierarchy and look for excessive nesting, inconsistent reservations, shares, or limits. Simplify unnecessary pools and document the purpose and policy of each remaining pool.

Exam-Relevant Notes

Shares are relative priorities, not guaranteed capacity.
Reservations provide guaranteed CPU or memory capacity and can affect admission control.
Limits cap consumption and can throttle a VM even when the host has unused resources.
CPU reservations use MHz; memory reservations use MB.
Expandable reservations allow a child pool to use unused capacity from its parent.
Resource behavior is evaluated within the hierarchy, so sibling scope matters.
A VM inherits the policy of its containing pool, but VM-level settings still interact with that policy.