VMware ESXi and vSphere Cluster Management

Memory Overcommitment in VMware ESXi Explained

Learn how VMware ESXi overcommits memory and manages pressure with ballooning, compression, sharing, and .vswp swapping.

What Is Memory Overcommitment?

Memory overcommitment means configuring virtual machines (VMs) with more combined virtual memory than the ESXi host has installed physical RAM. For example, a host with 64 GB of RAM might run VMs configured with 100 GB of virtual memory.

Overcommitment is viable because configured memory is not the same as memory actively used at every moment. A server VM may be configured with 16 GB but currently use only 4 GB. If several VMs have unused or reclaimable pages, ESXi can use the available physical memory for VMs with higher demand.

ESXi is VMware's bare-metal hypervisor. Its VMkernel manages hardware resources, including physical memory, and assigns host memory to VMs as they run.

Four memory quantities to distinguish

• Configured memory: The amount of virtual RAM assigned to a VM. This is the size shown in the VM's memory settings.
• Active memory: An estimate of pages recently used by the guest workload. It is a useful approximation of current demand, but it is not an exact real-time count of every page the guest considers important.
• Consumed memory: Host memory currently consumed on behalf of a VM, including relevant virtualization requirements. It can differ from active memory.
• Host physical memory: RAM installed in the ESXi server and available after accounting for ESXi itself and other host requirements.

ESXi also uses memory overhead: host RAM required for VM execution and virtualization structures. Memory overhead is separate from guest RAM and separate from the VM's datastore swap file.

Basic Capacity Calculation

Start with the sum of configured VM memory:

total configured VM memory = VM1 memory + VM2 memory + ... + VMn memory

Then compare that total with usable host physical RAM. The comparison identifies whether configured memory exceeds host capacity, but it does not by itself predict performance.

Worked example: five VMs on a 6 GB host

Suppose an ESXi host contains 6 GB of physical RAM and runs five VMs. Each VM is configured with 2 GB:

5 VMs × 2 GB each = 10 GB configured VM memory

The host therefore has 10 GB of configured guest memory backed by 6 GB of installed physical RAM. The configuration is overcommitted by 4 GB, or approximately 1.67 times the host's physical RAM before considering ESXi and VM overhead.

This environment can operate normally if the VMs do not simultaneously use all 10 GB. For example, if several VMs are idle and only a portion of each VM's memory is active, the VMkernel may satisfy demand without expensive disk swapping. If all five workloads become memory-intensive at the same time, contention can develop quickly.

How the VMkernel Manages Memory Pressure

The VMkernel continuously monitors host memory availability and VM demand. When one VM needs more memory while another has reclaimable pages, ESXi can reclaim memory from the lower-demand workload and make it available to the higher-demand workload.

Overcommitment is not automatically harmful. Memory contention is the condition that matters: demand for host memory exceeds readily available physical memory. Mild or temporary contention may have little visible effect. Sustained contention, especially when it causes guest paging or host swapping, can reduce application performance.

The exact behavior, availability, security treatment, and defaults of memory-management mechanisms can vary by ESXi or vSphere release and configuration. Always verify behavior against the version and settings in use.

ESXi Memory Reclamation Techniques

ESXi can use several mechanisms under pressure. The general progression moves from methods that avoid datastore I/O toward methods with greater performance cost:

1. Reuse or share suitable pages where applicable.
2. Reclaim memory through the guest balloon driver.
3. Compress suitable pages in host memory.
4. Swap VM memory to a datastore when other methods cannot provide enough space.

Ballooning: Reclaiming Underused Guest Memory

Ballooning is guest-assisted memory reclamation. A balloon driver supplied through VMware Tools, or the appropriate guest driver, runs inside the VM. When ESXi needs memory, it instructs the driver to inflate. The driver asks the guest operating system to allocate pages, preferably from memory the guest can reclaim safely, and those pages are returned to the hypervisor.

ESXi can then use the recovered host memory for another VM with higher demand. This is more informed than blindly taking arbitrary pages because the guest operating system knows which of its pages are reclaimable according to its own memory-management policies.

Ballooning requires a functioning compatible driver. Verify VMware Tools status and the balloon-driver health when ballooning is unexpectedly unavailable.

Ballooning is not free. If the guest is already short of memory, the guest operating system may respond by paging to its own virtual memory or swap device. That guest paging can cause application latency even though ESXi has not yet started datastore swapping.

Example: an idle VM and a busy application VM

Consider a lightly used file server VM and a busy database application VM on the same host. If the application VM needs more physical memory while the file server has reclaimable pages, ESXi may inflate the file server's balloon. The guest releases suitable pages, and the host assigns the recovered memory to the application VM.

If both VMs remain heavily active, ballooning cannot recover enough memory. ESXi may then use compression and, if pressure continues, the VM's .vswp file.

Memory Compression

Memory compression compresses suitable VM memory pages before ESXi resorts to disk-based swapping. The compressed pages remain in host memory, usually in a reserved compression cache.

Compression is an intermediate layer: it uses CPU cycles and cache space, but avoids the much slower datastore I/O required to write and read swapped pages. When a compressed page is needed, ESXi decompresses it.

Compression reduces the consequences of pressure but does not eliminate them. Severe or sustained pressure can exhaust useful compression capacity, increase CPU work, and eventually force swapping.

VMware ESXi Virtual Machine Swap Files

A .vswp file is an ESXi per-VM swap file stored on a datastore. It provides disk backing for VM memory that ESXi may need to swap when physical memory cannot be reclaimed sufficiently through other mechanisms.

A simplified potential swap-file relationship is:

potential .vswp capacity ≈ configured VM memory − memory reservation

The actual file behavior and size can depend on VM settings, release behavior, and other configuration details. A VM with 8 GB configured memory and a 2 GB reservation can have approximately 6 GB of potentially swappable VM memory represented by its swap-file capacity concept. A reservation covering the configured memory can reduce that potential to approximately zero, although the VM still requires memory overhead and other host resources.

Do not confuse the .vswp file with memory overhead. Overhead is host RAM used for virtualization structures and VM execution. The .vswp file is disk space used as backing for potentially swappable VM memory.

Datastore swapping is expensive because storage latency is far higher than RAM latency. A VM repeatedly reading and writing swapped pages can experience noticeable application delay, and concurrent swapping can saturate datastore I/O.

Reservations, Shares, Limits, and Admission

Reservations

A memory reservation guarantees a specified quantity of host physical memory for a VM, subject to the host or cluster's ability to satisfy the reservation during admission. Reserved memory is protected from ordinary reclamation and reduces the amount of configured memory that may need datastore swap backing.

Reservations improve predictability for important workloads, but they also reduce the memory available for flexible overcommitment. Capacity planning must account for all reservations, ESXi overhead, HA requirements, and growth headroom.

Shares

Memory shares provide relative priority during contention. A VM with more shares receives a larger relative allocation than a peer with fewer shares when both compete for the same resource. Shares do not create physical memory and do not guarantee a specific amount of RAM when the host is not able to satisfy demand.

Limits

A memory limit caps the memory available to a VM. A limit set below the VM's configured memory can create artificial pressure inside that VM even when the ESXi host has unused RAM. Use limits cautiously and investigate them whenever a VM reports memory pressure despite apparently adequate host capacity.

Admission and capacity implications

Reservations, host capacity, cluster design, and vSphere HA admission control are related. A cluster must retain enough capacity to restart protected VMs after a host failure. Do not size an overcommitted cluster only for normal-day demand; include failure capacity, workload growth, maintenance operations, and performance-critical reservations.

Monitoring Memory Pressure

Use the vSphere Client's host and cluster performance views to inspect active memory, consumed memory, ballooned memory, compressed memory, swapped memory, swap-in and swap-out activity, and memory contention. Review trends rather than relying on a single sample.

For real-time troubleshooting, open the ESXi performance utility:

esxtop

In the memory view, inspect ballooning, compression, swapping, swap-in, swap-out, and related availability or contention statistics. Metric names and displayed fields can vary by ESXi release, so interpret them with the product version's documentation and performance-counter definitions.

Also check the guest operating system. High guest paging with little or no ESXi host swapping may indicate that the VM itself is underprovisioned or constrained by a memory limit. High ESXi ballooning, compression, or host swapping indicates host-level contention, although ballooning can then cause guest paging as a consequence.

Key interpretation rules

• High active memory: Indicates real workload demand and is more meaningful for sizing than configured memory alone.
• High consumed memory: Shows substantial host-side consumption, including virtualization requirements.
• Sustained ballooning: Indicates that ESXi is reclaiming memory through guests. Check guest paging and application behavior.
• Compression activity: Indicates pressure and additional CPU/cache work, but is generally preferable to datastore swapping.
• Sustained host swapping or high swap-in latency: An urgent warning sign. Applications may experience severe latency.
• Memory contention: Correlate it with workload peaks, VM placement, reservations, limits, and shares.

Pressure Escalation Example

Imagine a host whose VMs are normally active at different times. Page sharing where applicable and ballooning provide enough relief when one workload becomes busy. A coordinated event then causes many VMs to become memory-intensive at once. Sharing and ballooning cannot recover enough pages, so ESXi compresses suitable pages in its compression cache. If demand remains high, ESXi begins using .vswp files. Swap-in and swap-out activity increases, datastore latency rises, and applications show noticeable delays.

This progression demonstrates why monitoring matters. The first sign of risk may be increased active memory and ballooning, while sustained swapping is evidence that the host has moved into a much more expensive state.

Benefits, Risks, and Sizing Guidance

Benefits

• Higher VM consolidation ratios can improve hardware utilization.
• Hosts can support workloads whose peaks occur at different times.
• Idle or lightly used configured memory does not have to remain permanently backed by separate physical RAM for every VM.
• Capacity can be allocated flexibly when reservations and performance requirements are understood.

Risks

• Correlated workload peaks can exhaust physical memory quickly.
• Ballooning may cause guest operating systems to page.
• Compression consumes CPU and reserved host cache space.
• Host swapping introduces datastore latency and can saturate storage I/O.
• Application performance can become unpredictable under contention.
• Insufficient headroom can interfere with maintenance, VM placement, or HA failover.

Planning approach

1. Measure active and consumed memory over representative busy periods, not only during quiet hours.
2. Identify workload concurrency and test correlated peak scenarios.
3. Separate performance-critical VMs from workloads that can tolerate reclamation or delay.
4. Set reservations where predictable memory access is required, and include those reservations in host and cluster capacity calculations.
5. Review VM limits and remove limits that create artificial pressure.
6. Provide growth headroom, maintenance capacity, and vSphere HA failover capacity.
7. Plan datastore capacity and performance for potential .vswp files as well as virtual disks and snapshots.
8. Use controlled overcommitment based on observed behavior, not on configured-memory totals alone.

A practical rule is to tolerate overcommitment only while the environment maintains acceptable active-memory performance and reclamation remains low-cost. Sustained ballooning, compression, or especially host swapping should trigger investigation rather than being treated as normal utilization.

Troubleshooting Checklist

A slow VM with sustained host swapping

1. Confirm ESXi swap activity and check datastore latency.
2. Determine whether host active-memory demand exceeds available capacity.
3. Review concurrent workload peaks and recent VM additions.
4. Inspect reservations, shares, and limits.
5. Reduce contention by migrating or powering off workloads where appropriate, adding host capacity, or rebalancing workloads. Faster storage may reduce symptoms but does not remove the underlying memory shortage.

High ballooning while the guest reports low available memory

1. Verify VMware Tools and the balloon-driver health.
2. Check the guest workload and its paging behavior.
3. Determine whether the guest is genuinely underprovisioned or is reacting to host contention.
4. Address host contention and increase VM memory only when application demand justifies it.

Memory pressure despite apparently adequate host RAM

1. Check for a restrictive VM memory limit.
2. Review the VM's reservation and shares relative to peer VMs.
3. Compare guest memory metrics with ESXi host metrics.
4. Raise or remove an unjustified limit and align resource settings with application requirements.

Unexpected datastore capacity consumption

1. Locate the VM's .vswp file.
2. Review configured memory and reservation settings.
3. Separate swap-file space from snapshots, virtual disks, and other datastore consumers.
4. Maintain adequate datastore capacity when changing VM memory or reservation settings.

Summary

• Memory overcommitment allows aggregate configured VM memory to exceed installed host RAM.
• The important distinction is between configured, active, consumed, and overhead memory.
• The VMkernel manages contention by reclaiming memory and reallocating it among VMs.
• Sharing where applicable, ballooning, compression, and hypervisor swapping represent increasingly costly pressure responses.
• Reservations protect memory and reduce potential .vswp requirements; shares set relative priority; limits can cause artificial pressure.
• Active-memory trends and contention metrics are more useful than configured totals alone.
• Sustained host swapping and high swap latency require prompt capacity or workload action.

For a related reference within this course, see Memory Overcommitment Explained.