VMware ESXi and vSphere Cluster Management

VMware vSphere Resource Management: Shares, Limits, and Reservations

Learn how vSphere shares, limits, and reservations control CPU and memory priority, maximum usage, minimum guarantees, and VM startup.

VMware vSphere is a virtualization platform for managing virtual infrastructure. An ESXi host runs multiple virtual machines (VMs) and provides their virtual CPU and physical-memory resources. Because the host has finite CPU processing capacity and physical RAM, competing workloads can require resource-management controls.

Shares, limits, and reservations answer different administrative questions: which VM should receive priority, how much a VM may consume at most, and how much capacity must be available for a VM at minimum.

Why resource management is needed

A virtual machine is a software-defined computer running on an ESXi host. Several VMs can run concurrently on the same host, sharing the host's physical CPU and memory.

Resource contention occurs when VM demand competes for a finite host resource and the combined demand cannot be served immediately at the desired level. For example, several VMs may become busy at the same time and request more CPU processing capacity than the host can provide.

Normal resource demand is not automatically a shortage. A VM can request CPU or memory while the host still has enough capacity to satisfy that request. Contention becomes significant when competing demand exceeds available capacity or when a configured control restricts access.

Shares prioritize access relative to other VMs during contention.
Limits restrict the maximum amount a VM may consume.
Reservations guarantee a minimum allocation and affect whether a VM can start.

Shares: relative priority

Shares are a relative weighting assigned separately for CPU and memory. When multiple VMs compete for the same resource, a VM with more shares receives preferential access compared with a VM with fewer shares.

Shares do not reserve a fixed amount of CPU or memory. They also do not establish a maximum resource ceiling. If there is no contention, a VM's share value may have little or no visible effect because the host can satisfy current demand.

How share comparisons work

Suppose a critical application VM has more CPU shares than a noncritical test VM. During CPU contention, the critical VM has a greater relative claim on available CPU capacity. The same comparison can be made independently for memory shares.

Share values should be evaluated relative to competing VMs, not as isolated numbers. Changing one VM's shares can change its position in the priority relationship with other VMs.

CPU shares influence relative CPU priority.
Memory shares influence relative memory priority.
CPU shares do not control memory priority.
Memory shares do not control CPU priority.

Example: prioritizing a business-critical VM

An organization runs a business-critical application VM and a noncritical development VM on one ESXi host. Assigning higher CPU and memory shares to the application VM gives it preferential access to each resource when the host is contended. This does not reserve a fixed quantity for the application VM and does not stop the development VM from using resources when capacity is available.

Limits: maximum consumption

A limit is the maximum amount of a specified resource that a VM is allowed to consume.

A CPU limit restricts the CPU capacity or processing cycles available to a VM. A memory limit restricts the VM's use of host physical memory. Limits can prevent a VM from consuming more than an intended amount, even if unused host capacity is currently available.

Examples of limits

A development VM can receive a CPU limit so it cannot use more processing capacity than the organization's policy allows.
A VM with controlled host-memory consumption can receive a memory limit.
A limit can constrain performance below current workload demand, regardless of spare capacity elsewhere on the host.

Reservations: minimum guaranteed allocation

A reservation is a minimum amount of a resource guaranteed to a VM, subject to the host having sufficient capacity. Reservations can be configured independently for CPU and memory.

A CPU reservation guarantees a minimum CPU allocation for the VM. A memory reservation guarantees a minimum allocation of host physical memory. A reservation is not necessarily the VM's maximum consumption: the VM may use more than the reservation when capacity and other controls permit it.

Admission control and VM startup

Admission control is the capacity check that prevents a VM from starting when its configured reservation cannot be guaranteed. Before powering on a VM, the host must have enough unreserved capacity to satisfy the reservation.

If a VM has a CPU or memory reservation and the ESXi host lacks sufficient available capacity, the VM may fail to power on. Reducing the reservation or making adequate capacity available can resolve the admission problem.

Example: guaranteeing an essential service

An essential service VM can receive CPU and memory reservations so that its minimum allocation is guaranteed before startup. The administrator must first validate host capacity and existing reservations. The reservation provides a minimum guarantee; it does not automatically cap the VM's usage at that value.

Shares, limits, and reservations compared

Mechanism	Primary purpose	Behavior during contention	Minimum guarantee	Maximum cap	Startup impact	Typical use case
Shares	Set relative priority	Higher-share VMs receive preferential access relative to lower-share VMs	No	No	Normally none	Prioritize a critical VM over a test VM
Limit	Restrict maximum consumption	The VM cannot consume beyond its configured limit	No	Yes	Usually does not provide a startup guarantee	Prevent a noncritical workload from using excessive CPU or memory
Reservation	Guarantee minimum allocation	The reserved amount must remain available for the VM	Yes	No, unless a separate limit is configured	Power-on can be denied if the reservation cannot be guaranteed	Guarantee capacity for an essential service

CPU and memory resource controls

Resource	Shares behavior	Limit behavior	Reservation behavior	Example administrative objective
CPU	Sets relative CPU priority during CPU contention	Caps CPU capacity or processing cycles available to the VM	Guarantees a minimum CPU allocation before startup	Prioritize a production application, cap development CPU use, or guarantee service capacity
Memory	Sets relative memory priority during memory contention	C2026aps the VM's use of host physical memory	Guarantees a minimum host physical-memory allocation before startup	Prioritize a critical VM, cap memory consumption, or guarantee essential-service memory

Using the mechanisms together

Shares, limits, and reservations are not interchangeable. The same VM and resource can have all three settings, with each setting serving a different purpose.

A reservation can provide a minimum guaranteed allocation.
Shares can give the VM priority over peers for resource access during contention.
A limit can establish an upper boundary on consumption.

For example, an essential service VM might have a CPU and memory reservation to ensure minimum capacity, higher shares than lower-priority VMs, and a limit to prevent uncontrolled growth. These settings must be reviewed together: a limit can restrict a VM even when its reservation is available, and shares cannot compensate for a limit that is too low.

Practical configuration approach

Identify whether the policy concerns priority, a maximum cap, or a minimum guarantee.
Select the resource independently: CPU, memory, or both.
Configure CPU shares to establish relative CPU priority where contention is expected.
Configure memory shares to establish relative memory priority where contention is expected.
Configure a CPU limit when a VM must not consume more than a defined processing capacity.
Configure a memory limit when host physical-memory use must be capped.
Configure CPU and memory reservations only when a minimum allocation is required.
Review available host capacity and existing reserved capacity before applying or increasing reservations.
Confirm that the configured reservations can be satisfied before powering on the VM.

Resource-control decision

Need relative priority during contention?  Configure shares.
Need a maximum consumption boundary?       Configure a limit.
Need guaranteed capacity before startup?    Configure a reservation.
Need all three behaviors?                   Configure each deliberately.

Operational planning considerations

Workloads needing preferential access

Use higher shares for workloads that should receive more favorable access than peers during genuine CPU or memory contention. Examples include business-critical applications compared with test or development workloads. Reassess share relationships when workload priorities change.

Workloads needing a consumption cap

Use limits for workloads that should be prevented from consuming excessive CPU or physical memory. Verify that the cap is compatible with the workload's normal and peak requirements. An unnecessarily low limit can cause poor performance even when the host appears to have spare capacity.

Workloads needing guaranteed capacity

Use reservations for essential services that require a minimum allocation before they start. Validate host capacity first because reservations consume capacity that must remain available for the guarantee. Do not treat a reservation as a maximum unless a separate limit is also configured.

Troubleshooting resource-control problems

A VM cannot start after a reservation is configured

The likely cause is that the ESXi host cannot guarantee the requested CPU or memory reservation.

Check the VM's configured CPU and memory reservations.
Review available host capacity and existing reserved capacity.
Determine whether the reservation should be reduced or whether sufficient capacity must be made available.

A VM performs poorly although the host appears to have spare capacity

A CPU or memory limit may be restricting the VM below its current demand. Review the configured CPU and memory limits, compare each cap with workload requirements, and adjust or remove an unnecessary limit according to policy.

A lower-priority VM receives less access during a busy period

Higher-share VMs may be receiving preferential access during contention. Verify that genuine CPU or memory contention exists, compare the affected VM's shares with competing VMs, and adjust shares if the workload priority model has changed.

Shares produce no noticeable improvement

Shares primarily influence allocation when the relevant resource is contended. Confirm that contention exists, check for CPU or memory limits that may be constraining the VM, and determine whether another resource or workload bottleneck explains the performance issue.

Key points to remember

Contention means competing demand for insufficient host resources; ordinary demand is not necessarily a shortage.
Shares define relative priority during contention and provide neither a fixed allocation nor a maximum.
Limits define maximum consumption and can constrain a VM even when unused host capacity exists.
Reservations define minimum guaranteed allocations and can prevent a VM from powering on when capacity is insufficient.
CPU and memory controls are configured independently.
Validate available capacity before assigning or increasing reservations.

For a broader introduction to these controls, see Resource Management Overview.