VMware ESXi and vSphere Cluster Management

VMware ESXi Resource Management: Shares, Limits, and Reservations

Learn how VMware vSphere and ESXi use shares, limits, and reservations to prioritize, cap, and guarantee VM CPU and memory resources.

Why ESXi Resource Management Matters

An ESXi host is the physical virtualization server that supplies CPU and physical memory to running virtual machines (VMs). Multiple VMs commonly run on one host, so they must share the same hardware resources.

Resource contention occurs when the combined demand from VMs exceeds the host's available CPU processing capacity or physical memory. Without resource policies, an intensive workload could reduce the resources available to other workloads.

VMware vSphere provides three primary controls for managing this situation:

  • Shares prioritize workloads relative to one another during contention.
  • Limits prevent a VM from consuming more than a defined maximum.
  • Reservations guarantee a minimum amount of CPU or memory for an important VM.

These controls help administrators guarantee minimum access when required, prevent excessive consumption, and prioritize workloads when demand is higher than available capacity.

Resources Governed by VM Settings

These settings primarily govern two resource types:

  • CPU: Host processing capacity that ESXi schedules for VMs.
  • Memory: Host physical RAM capacity used to support VM memory allocations.

CPU and memory settings are configured independently. A VM can have high CPU shares but ordinary memory shares, or a memory reservation without a CPU reservation. Always evaluate the policy separately for each resource.

Shares: Relative Priority

Shares are a relative weighting that tells ESXi how to prioritize a VM's access to a resource. Shares matter when VMs are competing for that same resource. A VM with more shares receives a larger relative portion of the contested capacity than a competing VM with fewer shares.

Shares are not a reservation and are not a maximum. They do not reserve capacity, impose a consumption ceiling, or guarantee performance when the host has insufficient resources. Share values only have meaning when compared with the shares assigned to other competing VMs.

CPU shares example

Suppose a production VM and a test VM compete for CPU capacity. If the production VM has twice as many CPU shares as the test VM, ESXi gives the production VM a larger relative entitlement while contention exists. The share setting does not provide a fixed number of GHz and does not guarantee that the production VM will always receive twice the CPU.

If the host has enough idle CPU, both VMs might receive all the processing capacity they need. In that case, the higher share value may have little visible effect.

Memory shares

Memory shares work the same way conceptually, but they prioritize access to host physical memory rather than CPU scheduling capacity. Compare memory shares only with the memory shares of VMs competing for memory on the relevant host or resource hierarchy.

Limits: A Maximum Consumption Ceiling

A limit is the maximum amount of a specific resource that a VM may consume.

  • A CPU limit caps the VM's processing capacity.
  • A memory limit caps the VM's use of host physical memory.

ESXi enforces the limit even when unused host capacity is available. This distinguishes a limit from shares: shares influence relative distribution during contention, while a limit restricts the VM's upper boundary in all conditions.

A limit is also different from a reservation. A limit says, “do not allow use above this value.” It does not promise that the VM will receive that value. A low, unintended limit can constrain performance even when host utilization appears low.

Limit example

A development VM may receive a CPU limit to keep it within an approved processing ceiling. If the host has idle CPU, the VM still cannot exceed that configured cap. This can be useful for deliberate workload control, but unnecessary limits should be avoided.

Reservations: A Guaranteed Minimum

A reservation is a guaranteed minimum amount of CPU or memory capacity for a VM. Reservations are intended for workloads that must have resource availability, such as a critical business service.

A reservation is a floor, not a cap. When capacity and policy allow, the VM may use more than its reservation. Shares can influence how additional contested capacity is distributed, and a limit can restrict the maximum.

Admission behavior

Admission control means that ESXi must be able to guarantee a VM's reservation before the VM can start. If the host cannot satisfy the requested CPU or memory reservation, the VM may fail to power on until capacity is made available or the reservation is changed.

Review the reservations already committed to other VMs and the host's available capacity before assigning or increasing a reservation.

Comparing the Three Mechanisms

MechanismPrimary purposeBehavior during contentionGuarantees a minimumSets a maximumRequires available capacity for VM startup
SharesPrioritize relative accessAllocates a larger or smaller relative portion compared with competing VMsNoNoNo
LimitsCap consumptionRestricts use at the configured ceilingNoYesNo
ReservationsGuarantee minimum capacityProtects the reserved amount when capacity is contestedYesNoYes

How Shares, Limits, and Reservations Work Together

A VM can have shares, a limit, and a reservation configured for the same resource. Interpret them in this practical order:

  1. The reservation establishes the minimum capacity that must be guaranteed.
  2. The limit establishes the maximum capacity the VM may consume.
  3. Shares influence how capacity between the minimum and maximum is distributed when competing VMs contend for the resource.

The controls have different purposes: reservations guarantee, limits cap, and shares prioritize. A high share value cannot override a limit, and a share value alone cannot create a guaranteed minimum.

ResourceShares behaviorLimit behaviorReservation behaviorExample use case
CPUPrioritizes processing capacity relative to competing VMsSets a ceiling on processing capacityGuarantees minimum CPU capacityProtect a production service or cap a development workload
MemoryPrioritizes access to host physical memory relative to competing VMsSets a ceiling on host physical memory useGuarantees minimum host memory capacityProtect a memory-sensitive application

Evaluate CPU and memory separately. A VM may need a CPU reservation but only higher memory shares, or a memory reservation while its CPU remains governed by normal shares.

Configuration Decision Guide

Administrative objectiveRecommended mechanismReasonKey caution
Prioritize a workload during contentionSharesProvides a higher relative entitlement than competing workloadsShares do not guarantee capacity
Prevent a workload from exceeding an approved capacityLimitEnforces a maximum consumption ceilingAn unnecessarily low limit can reduce performance
Guarantee a minimum resource allocationReservationAssures resource availability and affects VM admissionConfirm that host capacity can satisfy it
Protect a critical workload while avoiding unnecessary restrictionsReservation plus appropriate shares; add a limit only when requiredGuarantees the floor and prioritizes additional contested capacityDo not assume high shares replace a reservation

Planning and Validation Workflow

  1. Classify the workload. Decide whether it needs a guaranteed minimum, higher priority only, or a deliberate maximum.
  2. Choose the resource. Determine whether the requirement applies to CPU, memory, or both.
  3. Compare competing VMs. Shares are meaningful only relative to other workloads competing for the same resource.
  4. Avoid unnecessary limits. Apply a limit only when a maximum is part of the workload policy.
  5. Review host capacity. Before assigning a reservation, check available CPU or physical memory and reservations already committed to other VMs.
  6. Apply settings independently. Review CPU shares, limits, and reservations separately from the corresponding memory settings.
  7. Validate startup. Confirm that the VM can power on and that admission control can satisfy its reservations.
  8. Monitor after the change. Check for ongoing CPU or memory contention and confirm that the workload behaves as intended.

vSphere configuration checklist

CPU:    review shares -> optional reservation -> intentional limit
Memory: review shares -> optional reservation -> intentional limit
Host:   verify available capacity and hyperthreading status
After:  test VM startup and monitor contention

Hyperthreading Awareness

Hyperthreading is a processor capability that exposes logical execution threads to the ESXi host scheduler. It is relevant when assessing the host's available logical CPU scheduling capacity and planning CPU workloads.

Reviewing or enabling hyperthreading is a host-level consideration. It is separate from configuring per-VM CPU shares, limits, and reservations, and it is not a substitute for those resource-management policies. A host's hyperthreading capability does not remove the need to plan CPU capacity and monitor contention.

Troubleshooting Common Problems

A VM fails to start after a reservation is configured

The host may be unable to guarantee the requested CPU or memory reservation.

  1. Check the VM's reservation values.
  2. Review available host capacity and reservations committed to other VMs.
  3. Reduce the reservation, free capacity, or place the VM on a host that can satisfy the guarantee.

A VM performs poorly despite apparently idle CPU

A configured CPU limit may be restricting the VM below the capacity the host could otherwise provide.

  1. Inspect the VM CPU limit.
  2. Determine whether the cap is intentional.
  3. Increase or remove the limit if the policy allows additional CPU.

A high-share VM does not receive extra resources

Shares affect allocation only when competing VMs contend for the same resource.

  1. Confirm whether CPU or memory contention exists.
  2. Compare the VM's shares with those of competing VMs.
  3. Verify that a limit is not capping the VM.

A VM with high shares cannot exceed a particular usage level

A limit may be overriding the practical benefit of the higher share priority. Review the limit and reservation separately, confirm the intended maximum-consumption policy, and adjust the limit if higher utilization is appropriate.

Exam-Relevant Notes

  • Shares are relative: their effect depends on competing VMs and applies during contention.
  • Shares are not guarantees: they neither reserve capacity nor set a maximum.
  • Limits are ceilings: unused host capacity does not let a VM exceed its limit.
  • Reservations are floors: they guarantee a minimum but do not cap usage.
  • Reservations affect admission: the VM must be placed on a host able to honor the reservation before startup.
  • CPU and memory are independent: inspect and plan their settings separately.
  • Hyperthreading is host-level: it influences CPU-capacity planning but does not replace VM resource policies.

For prerequisite administration skills, review the VMware ESXi online course, adding an ESXi host to vCenter Server inventory, and admission control concepts.