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
| Mechanism | Primary purpose | Behavior during contention | Guarantees a minimum | Sets a maximum | Requires available capacity for VM startup |
|---|---|---|---|---|---|
| Shares | Prioritize relative access | Allocates a larger or smaller relative portion compared with competing VMs | No | No | No |
| Limits | Cap consumption | Restricts use at the configured ceiling | No | Yes | No |
| Reservations | Guarantee minimum capacity | Protects the reserved amount when capacity is contested | Yes | No | Yes |
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:
- The reservation establishes the minimum capacity that must be guaranteed.
- The limit establishes the maximum capacity the VM may consume.
- 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.
| Resource | Shares behavior | Limit behavior | Reservation behavior | Example use case |
|---|---|---|---|---|
| CPU | Prioritizes processing capacity relative to competing VMs | Sets a ceiling on processing capacity | Guarantees minimum CPU capacity | Protect a production service or cap a development workload |
| Memory | Prioritizes access to host physical memory relative to competing VMs | Sets a ceiling on host physical memory use | Guarantees minimum host memory capacity | Protect 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 objective | Recommended mechanism | Reason | Key caution |
|---|---|---|---|
| Prioritize a workload during contention | Shares | Provides a higher relative entitlement than competing workloads | Shares do not guarantee capacity |
| Prevent a workload from exceeding an approved capacity | Limit | Enforces a maximum consumption ceiling | An unnecessarily low limit can reduce performance |
| Guarantee a minimum resource allocation | Reservation | Assures resource availability and affects VM admission | Confirm that host capacity can satisfy it |
| Protect a critical workload while avoiding unnecessary restrictions | Reservation plus appropriate shares; add a limit only when required | Guarantees the floor and prioritizes additional contested capacity | Do not assume high shares replace a reservation |
Planning and Validation Workflow
- Classify the workload. Decide whether it needs a guaranteed minimum, higher priority only, or a deliberate maximum.
- Choose the resource. Determine whether the requirement applies to CPU, memory, or both.
- Compare competing VMs. Shares are meaningful only relative to other workloads competing for the same resource.
- Avoid unnecessary limits. Apply a limit only when a maximum is part of the workload policy.
- Review host capacity. Before assigning a reservation, check available CPU or physical memory and reservations already committed to other VMs.
- Apply settings independently. Review CPU shares, limits, and reservations separately from the corresponding memory settings.
- Validate startup. Confirm that the VM can power on and that admission control can satisfy its reservations.
- 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 contentionHyperthreading 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.
- Check the VM's reservation values.
- Review available host capacity and reservations committed to other VMs.
- 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.
- Inspect the VM CPU limit.
- Determine whether the cap is intentional.
- 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.
- Confirm whether CPU or memory contention exists.
- Compare the VM's shares with those of competing VMs.
- 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.