VMware ESXi and vSphere Cluster Management

How to Create and Configure a Resource Pool in VMware vSphere

Learn how to create a VMware vSphere resource pool, configure CPU and memory shares, reservations, limits, and assign virtual machines to it.

What Is a vSphere Resource Pool?

A resource pool is a logical vSphere container that controls how CPU and memory resources are distributed among member virtual machines and, where applicable, child resource pools. It does not permanently dedicate every resource to the pool. Instead, it defines allocation rules for times when workloads need to share capacity.

Administrators commonly create pools to separate workloads by department, application tier, business priority, tenant, or service requirement. For example, Production and Development pools can use different share priorities, while a pool for a critical application can have a carefully sized reservation.

Understand the Resource Pool Hierarchy

Resource pools are placed within the vSphere inventory hierarchy. The basic relationship is:

ESXi host or cluster
└── Root resource pool
    ├── Child resource pool
    │   ├── Virtual machine
    │   └── Virtual machine
    └── Virtual machine

The root resource pool is the top-level resource allocation container associated with a host or cluster. A child resource pool receives resources from its parent and shares those resources among its own virtual machines and nested pools.

A standalone ESXi host and a cluster can present different creation and placement options in the vSphere management interface. Always select the intended host or cluster before creating the pool. On a cluster, the pool participates in the cluster's available resource allocation; on a standalone host, it is associated with that host's resources.

Prerequisites and Planning

  • Use vCenter Server, the VMware management platform for administering hosts, clusters, virtual machines, and resource pools.
  • Confirm access to the vSphere inventory and to the target ESXi host or cluster.
  • Have the privileges required to create and manage resource pools and to move virtual machines. The exact privilege names depend on the vSphere version and assigned role.
  • Define the workload grouping before creating the pool. Examples include Production, Development, Finance, or a specific application tier.
  • Estimate expected CPU and memory demand and identify which groups are more important during contention.
  • Decide whether a reservation or limit is genuinely needed. Shares are often sufficient for prioritization.

Avoid creating pools without an allocation policy. Unnecessary pools increase hierarchy depth, make troubleshooting harder, and can obscure the effective resource settings inherited by virtual machines.

Create the Resource Pool

  1. Open the Hosts and Clusters inventory view in the vSphere management interface.
  2. Select the intended ESXi host or cluster.
  3. Open the selected object's context menu or actions menu and choose the action to create a New Resource Pool.
  4. Enter a meaningful resource pool name, such as Production, Development-Test, or Critical-Applications.
  5. Configure the CPU allocation settings.
  6. Configure the memory allocation settings.
  7. Review the settings before completing the wizard.
  8. Complete the wizard to create the pool.

Use names that describe ownership or service purpose rather than temporary project details. A clear hierarchy helps administrators identify the correct destination when moving VMs and makes performance analysis easier.

Configure CPU and Memory Allocation

CPU and memory allocation are configured independently. The same concepts apply to both resource types, but CPU and memory demand should be evaluated separately.

Shares
Applies to: CPU or memory.
Purpose: Sets relative priority between sibling pools or workloads.
During contention: A pool with more shares receives a larger proportion of available resources relative to pools with fewer shares.
Planning consideration: Use shares to express priority, especially when contention is occasional or variable.

Reservation
Applies to: CPU or memory.
Purpose: Establishes a guaranteed minimum amount of capacity for the pool when the required capacity is available.
During contention: vSphere attempts to protect the reserved amount from being taken by other allocations.
Planning consideration: Size reservations carefully and confirm that the parent, host, or cluster can satisfy them.

Limit
Applies to: CPU or memory.
Purpose: Caps the maximum amount the pool and its members may consume.
During contention: The pool cannot consume above the configured ceiling even if unused capacity exists elsewhere.
Planning consideration: Avoid restrictive limits unless a deliberate technical, tenant, or policy requirement exists.

Expandable reservation
Applies to: Reservations in a hierarchy.
Purpose: Allows a pool to request additional reserved resources from its parent when its own reservation is insufficient.
During contention: The request can use available reservation capacity in the parent, subject to the parent's rules and capacity.
Planning consideration: Enable it only when the hierarchy is designed to permit that resource borrowing.

Shares

Shares are relative priority values. They do not represent a fixed quantity of CPU or memory. When there is no contention, shares may have little visible effect because workloads can use available capacity. During contention, shares influence how resources are divided between competing sibling pools or workloads.

For example, assigning higher CPU and memory shares to a Production pool than to a Development pool gives Production preferential access when both require more resources than are available. Shares should reflect relative importance, not an arbitrary number chosen without comparing sibling pools.

Reservations

A reservation specifies a minimum CPU or memory capacity that vSphere should keep available for the pool, provided the required capacity can be scheduled. Reservations consume capacity from the parent resource pool, host, or cluster. A large reservation can therefore prevent other pools from starting workloads or satisfying their own reservations.

Use reservations for workloads with a genuine guaranteed-capacity requirement. Before applying one, check unreserved capacity and consider VM growth, failover requirements, and other workloads that share the same parent.

Limits

A limit is a maximum amount of CPU or memory that the pool may consume. A limit can restrict a workload even when the host or cluster has unused capacity. This makes limits a common source of avoidable performance problems.

For example, a test environment might need a firm consumption ceiling under a tenant or policy agreement. Without such a requirement, use shares for prioritization rather than imposing a low limit.

Expandable Reservations

An expandable reservation allows a child pool to obtain additional reserved capacity from its parent when its own reservation is not enough. This setting can be useful in a planned hierarchy, but it also means a child pool may consume reservation capacity that administrators expected other siblings to use. Review parent and child settings together.

How Parent and Child Settings Affect VMs

A virtual machine in a pool is subject to the pool's effective allocation policy. A child pool cannot obtain more resources than its parent can provide, even if the child has high shares or a large reservation. Similarly, a restrictive parent limit can constrain every child and VM beneath it.

Nested pools divide the resources assigned by their parent. If a parent allocates resources among two child pools, each child then distributes its effective allocation among its own members. Review the complete path from the root pool through each parent and child when diagnosing an unexpected entitlement or performance result.

Assign Virtual Machines to the Pool

  1. Locate the existing virtual machine in the Hosts and Clusters inventory.
  2. Use supported drag-and-drop or a move action to place the VM in the new resource pool.
  3. Before confirming, validate the destination name and its position beneath the intended host, cluster, or parent pool.
  4. Confirm the move.
  5. Repeat for the other VMs that belong to the workload group.

After placement, the VM becomes a member of the pool and is subject to that pool's allocation policy. VMs can be moved between pools later when their workload requirements, ownership, or priority changes.

For example, an existing VM can be moved from the root pool into a departmental pool. Verify both its new inventory location and its effective CPU and memory policy after the move.

Resource Pool Design Examples

Production
Recommended pool structure: A Production pool beneath the appropriate host or cluster resource hierarchy.
Share priority: Higher than Development and Test when production service is more important.
Reservation approach: Reserve only capacity required by critical production services.
Limit guidance: Do not apply a limit unless a documented policy requires one.

Development and Test
Recommended pool structure: A separate Development-Test pool for nonproduction VMs.
Share priority: Lower than Production during contention.
Reservation approach: Usually no reservation unless a particular test service has a defined minimum requirement.
Limit guidance: Use a limit only when a firm consumption ceiling is needed.

Business-Critical Applications
Recommended pool structure: A dedicated child pool for the application tier, with a clear parent relationship.
Share priority: High relative to less important sibling pools.
Reservation approach: Carefully sized CPU and memory reservations after confirming host or cluster capacity.
Limit guidance: Avoid a limit that conflicts with the application's growth requirements.

Departmental Workloads
Recommended pool structure: Separate pools by department when ownership, priority, or service requirements differ.
Share priority: Set relative to the other departments and documented business priorities.
Reservation approach: Use only for an agreed minimum service level.
Limit guidance: Prefer shares unless departmental consumption must be capped.

Verify the Configuration

  1. Confirm that the resource pool appears beneath the selected host or cluster in the inventory hierarchy.
  2. Expand the pool and verify that the intended virtual machines are members.
  3. Review CPU shares, CPU reservation, CPU limit, and CPU expandable reservation.
  4. Review the corresponding memory settings.
  5. Check parent pools for settings that could constrain the new pool.
  6. Open vCenter performance charts and review pool-level and VM-level CPU and memory usage.
  7. Where available, compare usage, demand, contention, and entitlement to determine whether the pool is receiving the expected resources.
  8. Check whether reservations can be satisfied and whether a limit is restricting a workload.

Entitlement represents the resources a workload is entitled to receive under the current allocation rules. Comparing entitlement with actual usage and demand helps distinguish an underprovisioned workload from an idle one. A VM with low usage but high demand may be constrained by contention, a limit, or insufficient effective entitlement.

Operational Guidance

  • Use shares for relative prioritization when contention occurs.
  • Use reservations only for workloads that require guaranteed capacity, and confirm available host or cluster capacity first.
  • Avoid restrictive limits unless there is a deliberate policy reason.
  • Keep pool names and parent-child relationships understandable.
  • Avoid overly deep or overlapping designs that make effective allocation difficult to predict.
  • Reassess shares, reservations, and limits as VM counts and workload demand change.
  • Document why a pool exists and what its allocation settings are intended to achieve.

Troubleshooting

The Create Resource Pool Option Is Unavailable

Possible causes include selecting the wrong inventory object, lacking the required resource pool or host/cluster privileges, or working outside the appropriate inventory view.

  • Return to Hosts and Clusters.
  • Select the correct ESXi host or cluster rather than an unrelated inventory object.
  • Ask a vSphere administrator to confirm the assigned role and privileges.
  • Retry from the selected object's actions menu or context menu.

A Reservation Cannot Be Configured or Is Not Satisfied

The parent pool, host, or cluster may not have enough unreserved CPU or memory. A restrictive parent allocation setting can also prevent the requested reservation, or the request may simply be too large.

  • Review available capacity and reservations at each parent level.
  • Reduce the requested reservation or free capacity.
  • Review whether expandable reservation is appropriate for the hierarchy.
  • Check capacity planning requirements before increasing reservations.

A VM Performs Poorly After Assignment

Possible causes include low shares during contention, an unnecessary CPU or memory limit, competition with higher-priority sibling pools, or insufficient underlying host or cluster capacity.

  • Compare the pool's shares with sibling pool shares.
  • Check CPU and memory limits at the VM, pool, and parent levels.
  • Use vCenter performance charts to examine usage, demand, entitlement, and contention.
  • Adjust the allocation design or add capacity when the evidence justifies it.

A VM Was Placed in the Wrong Pool

The wrong target may have been selected during drag-and-drop or a move operation, especially in a deep hierarchy.

  • Move the VM to the intended resource pool.
  • Confirm the destination before completing future moves.
  • Adopt clear pool names and document the intended hierarchy.

Exam-Relevant Notes

  • Shares are relative priorities used primarily during contention; they are not guaranteed capacity.
  • Reservations establish minimum capacity requirements, subject to the parent and available capacity.
  • Limits cap consumption and can restrict a VM even when unused resources exist.
  • Expandable reservations allow a child pool to obtain additional reserved capacity from its parent when permitted.
  • A child pool receives resources from its parent, so parent settings can constrain every descendant.
  • Resource pools manage aggregate CPU and memory allocation for their members; they do not permanently dedicate all host resources to the pool.

For related guidance, see Create Resource Pool.