VMware ESXi and vSphere Cluster Management

VMware ESXi Memory Overcommitment Explained

Learn how ESXi overcommits VM memory, tracks active and consumed memory, and uses ballooning, compression, and .vswp swapping under pressure.

Memory overcommitment is a common virtualization technique in which an ESXi host runs virtual machines whose combined configured memory is greater than the host's physical RAM. This can improve consolidation, but it requires careful monitoring because physical memory remains finite.

This lesson explains how ESXi accounts for memory, how the VMkernel responds to pressure, and how to plan for ballooning, compression, host swapping, VM overhead, reservations, and datastore capacity.

What Memory Overcommitment Means

Memory overcommitment occurs when the total configured memory of powered-on virtual machines exceeds the physical RAM available on an ESXi host.

For example, a host with 6 GB of physical RAM could run five virtual machines configured with 2 GB each. The VMs have 10 GB of configured memory in total, even though the host has only 6 GB of physical RAM.

Configured memory is a reservation in the VM's hardware configuration, not a guarantee that the guest workload is continuously using every byte. A VM may be configured with 2 GB but actively use only a few hundred megabytes during a particular measurement interval. The memory pages that a workload is actively using are called active memory.

Overcommitment can therefore work because workloads often have different usage patterns. Some VMs may be idle while another is busy. Even active applications may not touch their entire configured allocation at the same time. ESXi can use this difference between configured capacity and current demand to consolidate more VMs on one host.

Basic ESXi Memory Accounting

Several memory terms describe different parts of host and VM memory usage. Confusing these measurements can lead to incorrect capacity decisions.

ESXi is VMware's bare-metal hypervisor platform. Its VMkernel is the hypervisor kernel that manages host resources, including CPU, physical memory, storage, and networking.

VMkernel needs memory for its own operation. Each running VM also consumes memory overhead to maintain virtualization structures and run its virtual hardware. Consequently, the host cannot treat all installed RAM as guest-assignable RAM, and the total of VM configured memory is not a complete view of host memory use.

Worked Example: A 6 GB Host and Five 2 GB VMs

Consider an ESXi host with 6 GB of physical RAM. Five VMs are powered on, and each VM is configured with 2 GB.

The aggregate configured memory is 10 GB, which exceeds the 6 GB physical-memory pool by 4 GB. This is an overcommitted configuration.

The configuration may remain viable when only one VM is busy and the other four are largely idle. For instance, the busy VM may actively use most of its 2 GB while the other VMs use much less than their configured allocations. ESXi may reclaim less useful memory from low-activity guests if necessary.

The situation changes when several VMs become busy simultaneously. If their combined active demand, VM overhead, and VMkernel requirements approach or exceed available physical RAM, ESXi must reclaim memory. The VMs may continue running, but their performance can decline as reclamation becomes more expensive.

How the VMkernel Handles Memory Pressure

Memory pressure occurs when the host has insufficient readily available physical memory to satisfy current VM and VMkernel demand. VMkernel attempts to make memory available to VMs that currently need it rather than treating all VM allocations as equally urgent.

The general progression is:

1. Normal operation: Physical RAM is sufficient for current active demand, overhead, and VMkernel activity. No significant reclamation is required.
2. Guest-cooperative reclamation: ESXi can use the VMware Tools balloon driver to ask a guest operating system to release memory that it considers less useful.
3. Memory compression: ESXi compresses selected pages and keeps them in RAM, reducing the need to write those pages to storage.
4. Host swapping: If pressure remains, ESXi can write VM memory pages to a per-VM .vswp file on a datastore.

These mechanisms reduce the chance of an immediate VM failure, but they do not make physical memory unlimited. Each method has a cost, and sustained use of the later methods is a capacity or workload warning.

Idle-Memory Reclamation and Ballooning

Memory reclamation means that VMkernel recovers or reduces memory use so that capacity can be assigned where it is currently needed. One important method is ballooning.

Ballooning is guest-cooperative reclamation performed through the VMware Tools balloon driver. When the host needs memory, the driver requests memory from the guest operating system. The guest then chooses pages it considers less useful and makes that memory available to the balloon driver. ESXi can use the recovered host capacity elsewhere.

This approach is preferable to immediately taking arbitrary pages from a guest because the guest operating system understands its own memory state. It may be able to release cached data or other low-value pages while protecting memory that applications actively need.

Ballooning requires VMware Tools and a functioning balloon driver in the guest. If VMware Tools is not installed, is not running, is outdated, or the driver is unavailable, ESXi may need to use compression or host-level swapping sooner.

Ballooning is not automatically proof of failure. Short periods can occur in a deliberately overcommitted environment. Sustained or increasing ballooning, especially alongside compression and swapping, indicates that demand is exceeding comfortable host capacity.

Memory Compression

ESXi memory compression is enabled by default. It is a pressure-response mechanism used before or alongside more expensive disk swapping.

ESXi selects suitable memory pages, compresses them, and keeps the compressed data in host RAM. A compressed page occupies less physical capacity than its uncompressed form. When a VM accesses the page, ESXi decompresses it.

Compression can perform better than writing the page to a datastore because RAM is much faster than storage and avoids some storage I/O and latency. However, compression consumes CPU resources and compressed data still occupies RAM. Its effectiveness depends on how well the pages compress and how frequently they are accessed.

Compression is therefore a way to reduce the severity of memory pressure, not a replacement for adequate RAM. Persistent compression activity should be investigated together with active memory, ballooning, swapping, workload behavior, and host capacity.

ESXi Swapping and the VM Swap File

When physical memory remains insufficient, ESXi can swap VM memory pages to storage. The per-VM swap file uses the .vswp extension and resides on a datastore.

For example, a VM may have a file such as server01.vswp associated with its running configuration. The file provides space that ESXi can use if it must remove VM memory pages from physical RAM.

Storage is substantially slower than RAM, particularly when the datastore has high latency or competing workloads. If a VM repeatedly accesses pages that have been swapped out, ESXi must read them back from storage. This can cause application delays, guest operating system stalls, and generally poor VM performance.

The ESXi .vswp file is different from a guest operating system page file or swap partition:

Datastore planning must include potential .vswp space in addition to virtual disks, snapshots, templates, and other files. A VM may fail to power on or a datastore may become critically full if swap-file requirements were omitted from the design.

Memory Overhead

VM memory overhead is host memory consumed to run and virtualize a VM in addition to the guest RAM configured for that VM. The VM's virtual hardware and configuration influence the amount of overhead.

Overhead varies with VM configuration, so there is no single fixed overhead value that applies to every VM. Larger or more complex virtual hardware configurations can require different amounts of host memory.

Overhead matters because a host must provide memory for:

• The VMkernel and ESXi services.
• The configured guest memory of running VMs.
• Per-VM virtualization structures and memory overhead.
• Temporary and operational requirements associated with memory management.

Overcommitment calculations based only on the sum of configured guest RAM can therefore be optimistic. Include overhead when estimating how much host capacity can safely support a VM population.

Comparing ESXi Memory-Pressure Mechanisms

Reservations, Limits, and Shares

VM memory settings influence how ESXi schedules and protects memory:

• Configured memory size: The amount of virtual RAM presented to the guest OS.
• Memory reservation: A configured guarantee of host physical memory for a VM. Reservations reduce the amount of memory available for flexible overcommitment and must be planned across the host or cluster.
• Memory limit: An upper bound on the host memory a VM can consume. A limit lower than configured memory can cause unexpected guest performance problems and should be used deliberately.
• Shares: A relative priority used to decide which VMs receive memory preferentially when there is contention. Shares do not create additional RAM or guarantee capacity when the host is not under pressure.

Reservations can alter overcommitment behavior substantially. A highly reserved environment may have less flexible capacity than a simple configured-memory calculation suggests. Review reservations together with workload criticality, failover requirements, and expected peak demand.

Operational Guidance and Best Practices

• Use controlled overcommitment to improve consolidation efficiency, but base the decision on observed workload behavior rather than configured memory alone.
• Monitor host memory pressure, active and consumed memory, ballooning, compression, and swapping in the vSphere Client.
• Install and maintain VMware Tools so the guest balloon driver can participate in cooperative reclamation.
• Reserve enough host capacity for peak simultaneous demand, VMkernel activity, and VM overhead.
• Reserve enough datastore capacity for VM files, snapshots, and possible .vswp files.
• Check datastore latency and throughput. A datastore that is adequate for ordinary VM storage may perform poorly during heavy swap activity.
• Treat sustained host swapping as a sign that the host is underprovisioned or that VM allocations and workloads need adjustment.
• Review oversized VM configurations. Assigning more virtual RAM than an application uses can increase consolidation pressure without improving performance.
• Use reservations only when a workload needs a guaranteed minimum and account for their effect on other VMs.
• Rebalance VMs, add host RAM, add hosts, or reduce concurrent demand when memory pressure is persistent.

For broader host administration context, see the VMware ESXi online course. Datastore designs also affect VM swap-file planning; for example, review the material on a datastore in Virtual SAN.

Monitoring and Troubleshooting

VMs become slow when host memory use is high

Likely causes include sustained host memory pressure, ESXi swapping to a datastore, or a slow or overloaded datastore handling .vswp I/O.

1. Check host and VM swapping activity in the vSphere Client.
2. Check compression and ballooning indicators.
3. Review datastore latency and free capacity.
4. Determine whether workload demand changed or too many VMs became active at the same time.
5. Reduce concurrent memory demand, rebalance VMs, add host RAM or hosts, or improve datastore performance where swapping cannot be avoided.
6. Review excessive VM allocations and reservations.

Ballooning is absent or ineffective

Possible causes include VMware Tools not being installed, not running, or being outdated; an unavailable balloon driver; or a guest that cannot readily release memory.

1. Verify VMware Tools status for affected VMs.
2. Check guest driver status and host memory metrics.
3. Determine whether ESXi is using compression or swapping instead.
4. Install, start, or update VMware Tools as appropriate.
5. Assess guest memory demand and host capacity. Do not treat ballooning as the only capacity strategy.

A VM cannot power on or a datastore becomes critically full

Insufficient datastore space for VM swap-file creation is one possible cause. Other VM files, including snapshots, may also consume the remaining capacity.

1. Review datastore free space.
2. Identify swap-file placement and the memory settings of affected VMs.
3. Check for competing space consumers such as snapshots.
4. Free or add datastore capacity and reconsider swap-file placement according to the environment's design.
5. Adjust VM memory only after evaluating the workload's actual needs.

Exam-Relevant Summary

• Memory overcommitment means aggregate configured VM memory is greater than available host physical RAM.
• Configured memory is not the same as active memory. Workloads may use only part of their configured allocation.
• VMkernel manages host memory and uses reclamation to make capacity available to VMs that currently need it.
• Ballooning uses the VMware Tools balloon driver and asks the guest OS to select memory to release.
• Memory compression keeps selected pages compressed in RAM and is enabled by default.
• Host swapping writes VM memory pages to a datastore-based .vswp file and is generally more expensive than ballooning or compression.
• The ESXi .vswp file is not the same as a guest OS page file or swap partition.
• VM memory overhead consumes host RAM beyond configured guest memory.
• Reservations guarantee host physical memory but reduce flexible overcommitment capacity.
• Sustained ballooning, compression, or especially swapping requires investigation and may indicate inadequate host or datastore capacity.