4.2 Resource Allocation: Shares, Reservations & Limits

4.2 Resource Allocation: Shares, Reservations & Limits

In a multi-tenant enterprise private cloud, virtual machines share a common substrate of physical server hardware. When workload demands exceed physical compute or memory capacity, the ESXi VMkernel must arbitrate resource distribution deterministically. VMware vSphere provides three foundational allocation primitives—Shares, Reservations, and Limits—to control resource entitlement and contention. Application performance also depends on storage, networking, guest behavior and available capacity.

---

Resource Allocation Fundamentals: CPU (MHz) vs. Memory (MB/GB)

The hypervisor manages two distinct physical resource domains:

• CPU Allocation: Measured in Megahertz (MHz) or Gigahertz (GHz). Physical CPU execution is time-sliced across physical cores (pCPUs) by the VMkernel proportional share scheduler. Because CPU is a non-fungible, non-storable resource (idle CPU cycles cannot be saved for later), contention is managed by scheduling thread execution queues and adjusting time slices.
• Memory Allocation: Measured in Megabytes (MB) or Gigabytes (GB). Physical memory consists of physical DRAM addresses (HPAs). Unlike CPU cycles, memory pages are stateful and persistent; a physical page allocated to one VM cannot be reassigned to another without first reclaiming it through Transparent Page Sharing, ballooning, compression, or hypervisor swapping.

---

Proportional Shares: Allocation Values & Contention Dynamics

Shares specify the relative priority or proportional weight of a virtual machine to access physical resources only when there is resource contention.

The Operational Law of Shares: Contention vs. Non-Contention

Important: Shares have zero effect when physical resources are unconstrained.

If an ESXi host operates at 30% aggregate CPU utilization, an idle low-priority virtual machine configured with Low shares can consume up to 100% of its provisioned vCPUs. The hypervisor does not artificially restrict or throttle workloads based on shares when surplus physical capacity exists. Shares are activated and enforced by the VMkernel scheduler only when the demand from all runnable threads exceeds the physical capacity of the host or resource pool.

Standard Share Values & Relative Weights

VMware provides standard pre-defined share tiers, which scale proportionally with the virtual machine's configured compute sizing:

The Proportional Share Formula

For equally demanding sibling workloads without differing reservations or limits, a simplified proportional-share calculation illustrates relative priority:

                                  Shares(VM_i)
Illustrative Share Fraction(VM_i) = --------------------  x Total Available Resources
                              Sum of All Active Shares

Sizing Multiplier Nuance

Because standard shares are allocated per vCPU and per MB of RAM, sizing directly impacts overall priority. Consider an ESXi host running two VMs under 100% CPU contention:

• VM-1 (Database): 8 vCPUs configured with Normal shares; total shares equal 8 multiplied by 1,000, resulting in 8,000 CPU shares.
• VM-2 (App Server): 2 vCPUs configured with High shares; total shares equal 2 multiplied by 2,000, resulting in 4,000 CPU shares.

Even though VM-2 has "High" shares and VM-1 has "Normal" shares, VM-1 receives twice the total scheduling entitlement (8,000 / 12,000 = 66.7%) compared to VM-2 (4,000 / 12,000 = 33.3%) because of its larger compute footprint. When equal priority between differently sized VMs is desired, administrators must utilize Custom shares.

---

Resource Reservations: Guaranteed Commitments & Power-On Admission Control

A Reservation defines an explicit, guaranteed floor of physical resources committed to a virtual machine. The reservation establishes guaranteed resource entitlement subject to admission control:

• Reservation Entitlement: A CPU reservation guarantees scheduling capacity when needed; it does not pin exclusive physical cores. Idle CPU capacity can be used by other workloads. Memory reservations protect the reserved guest memory from host reclamation. Account for both reservations and overhead when checking placement.
• Power-On Admission Control: When an administrator powers on a virtual machine configured with reservations, ESXi and vCenter execute strict admission control validation. The hypervisor checks if the unreserved physical capacity of the host (or resource pool) is greater than or equal to the requested reservation plus hypervisor virtualization overhead. If insufficient unreserved physical capacity exists, the virtual machine is prohibited from powering on, generating an admission control failure error.

---

Memory Reservations & Datastore Swap File (.vswp) Dynamics

One of the most critical architectural mechanisms tested on the 2V0-16.25 examination is the direct causal relationship between a virtual machine's memory reservation and the size of its datastore swap file ([vmname].vswp).

The Swap Sizing Equation

When a virtual machine powers on, ESXi must guarantee that in the catastrophic event of severe physical memory exhaustion, every configured byte of guest RAM can be backed by physical storage. The VMkernel guarantees this by creating a virtual swap file (.vswp) on the VM's datastore according to this strict formula:

Swap File Size (.vswp) = Configured Memory - Reserved Memory

(Note: A small auxiliary swap file may also be created for VMkernel internal process overhead, but the main guest swap file strictly matches the formula above).

Concrete Architectural Scenarios

Architectural Implications for Storage Sizing

In large VDI or server consolidation clusters with thousands of virtual machines and default reservations (0 MB), the aggregate size of .vswp files can consume terabytes of high-performance datastore capacity. In contrast, configuring a 100% memory reservation reduces .vswp datastore allocations to zero bytes, preserving storage space and preventing hypervisor swapping latency at the cost of reducing host memory overcommitment flexibility.

---

Limits: Mechanics, Use Cases & Performance Hazards

A Limit specifies an absolute, non-negotiable ceiling on the consumption of CPU cycles (MHz) or memory (MB) that a virtual machine can consume. By default, both CPU and memory limits are set to Unlimited.

Operational Hazards of Limits

Setting hard limits on virtual machines in production enterprise environments is strongly discouraged by VMware due to severe architectural pitfalls:

1. CPU Limit Bottleneck: If an 8-vCPU virtual machine hosting a relational database is configured with a CPU limit of 2,000 MHz, the VMkernel artificially caps its execution once that threshold is reached. Even if the underlying physical host cores are 95% idle, the database threads are forcefully throttled into ready queues (%RDY climbs), creating synthetic application performance degradation.
2. Memory Limit Swapping Trap: If a virtual machine configured with 32 GB of vRAM is assigned a hard memory limit of 16 GB, the hypervisor prohibits the VM from consuming more than 16 GB of host physical DRAM. The moment the guest OS attempts to touch more than 16 GB of memory, ESXi forces the vmmemctl balloon driver to inflate or immediately begins hypervisor swapping guest memory to the .vswp file, inducing massive disk I/O latency despite abundant free physical RAM across the host.

Valid Use Cases for Limits

Limits should be restricted to isolated non-production environments:

• Constraining runaway test/development workloads from impacting shared staging clusters.
• Enforcing strict contractual tiering in external multi-tenant service provider architectures.

---

Resource Pools & Expandable Reservations

A Resource Pool is a logical abstraction that compartmentalizes CPU and memory allocations across a group of virtual machines or child pools within a standalone host or DRS cluster.

Fixed vs. Expandable Reservations

When configuring a child resource pool, the administrator specifies its reservation and whether that reservation is Expandable:

• Fixed Reservation (Expandable = Disabled): The pool can only satisfy reservations from its own locally configured reservation bucket. If all 32 GB of a pool's reservation is consumed by running VMs, attempting to power on an additional VM requiring a 4 GB reservation will immediately fail admission control—even if the parent cluster has hundreds of gigabytes of unreserved physical memory.
• Expandable Reservation (Expandable = Enabled, Default): If a child pool lacks sufficient local unreserved capacity to satisfy a power-on request or reservation increase, it dynamically queries its parent resource pool (and recursively up the tree to the cluster root). If the parent holds unreserved capacity, the child temporarily borrows the required resources, satisfying admission control and allowing the workload to power on.

---

Resource Allocation Comparison Matrix

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Review Takeaways

• Shares set relative priority during contention; they do not cap idle capacity.
• Reservations guarantee entitlement and affect admission control; CPU reservations do not pin exclusive cores.
• In the standard example, 64 GB configured RAM minus a 48 GB reservation leaves a 16 GB main guest swap file.
• Limits can constrain a VM despite spare physical capacity; expandable pool reservations can obtain eligible parent capacity.