Vmware Esxi

VMware ESXi Memory Management Technologies

Learn how the ESXi VMkernel manages memory overcommitment with TPS, ballooning, compression, SSD-backed swapping, and disk swapping.

VMware ESXi can run multiple virtual machines (VMs) on one host, even when the VMs' combined configured memory is greater than the host's installed RAM. This is called memory overcommitment. It works because VMs often do not actively use all of their assigned memory at the same time.

When active VM memory demand exceeds readily available host physical memory, the host experiences memory contention. The ESXi VMkernel—the hypervisor kernel responsible for managing host hardware resources—uses several reclamation technologies to reduce pressure and keep workloads running.

This lesson presents the technologies in the following progression: Transparent Page Sharing (TPS), ballooning, memory compression, host-level SSD swapping, and disk swapping. They are complementary mechanisms, not mutually exclusive choices. Their performance costs differ, and disk-based swapping has the greatest penalty because storage is much slower than RAM.

How the ESXi VMkernel Manages Memory

Physical memory is the RAM installed in the ESXi host. Each VM presents memory to its guest operating system, such as Windows or Linux, but the VMkernel controls which host RAM backs that virtual memory.

A memory page is a fixed-size unit of memory managed by operating systems and hypervisors. The VMkernel tracks these pages and decides how to provide memory to VMs, reclaim memory during contention, and preserve acceptable performance.

Memory overcommitment can be useful when workloads have variable or nonconcurrent demand. For example, ten lightly used VMs might be configured with more total memory than the host contains, while their combined active use remains within the host's capacity.

Overcommitment becomes risky when many VMs are memory-intensive, latency-sensitive, or consistently busy at the same time. ESXi then needs to reclaim memory. It attempts lower-cost techniques before relying heavily on disk I/O:

1. Find identical pages that can be shared.
2. Ask guests to release less-active memory through ballooning.
3. Compress selected pages in host memory.
4. Use an SSD-backed host cache for swap-related operations when configured.
5. Swap VM memory pages to a VM swap file as a last resort.

Maintaining adequate physical RAM is still the best way to avoid sustained reclamation activity. Reclamation is a capacity and workload-placement signal, not a substitute for sufficient memory.

Transparent Page Sharing (TPS)

Transparent Page Sharing identifies memory pages with identical contents and stores one shared physical copy instead of separate copies for each VM. The VMs can continue to use their configured memory, while the host consumes less physical RAM for duplicated content.

For example, several similarly configured VMs may contain identical operating-system code or other repeated data. TPS can map those matching pages to one physical page. This increases the host's effective memory capacity and can support greater memory overcommitment.

TPS is transparent to the guest. A guest operating system can still believe that its VM has the full configured memory allocation; page sharing is a host-side physical-memory optimization rather than a reduction in the guest-visible allocation.

If one VM modifies a shared page, it cannot change the copy used by the other VMs. The VMkernel creates a private copy for the modifying VM, while the other VMs continue using the original shared page. This behavior is commonly described as copy-on-write.

TPS example

Suppose two VMs contain a page with exactly the same contents:

VM-A page X  -- identical contents --> one shared physical page
VM-B page X  -- identical contents --> one shared physical page

If VM-A changes its page, the mapping becomes:

VM-A page X  -- changed contents --> private physical copy
VM-B page X  -- original contents --> original shared physical page

TPS reduces duplicated physical storage, but it does not guarantee that all pages can be shared. Pages with different contents require separate physical copies.

Ballooning

Ballooning is guest-assisted memory reclamation initiated by the VMkernel during host memory pressure. The VMware Tools balloon driver is called vmmemctl.

Ballooning depends on VMware Tools being installed and functioning inside the guest. The guest must also have a working balloon driver. Without that driver, the VM cannot effectively respond to the VMkernel's ballooning request.

How ballooning works

1. The VMkernel detects memory pressure and requests memory reclamation from a VM.
2. The vmmemctl driver inside the guest allocates or pins guest memory as its balloon inflates.
3. The guest operating system sees reduced memory available for other work.
4. The guest OS uses its own memory-management policies to release less-active memory, potentially allowing the VMkernel to reuse that host memory elsewhere.

Ballooning is generally preferable to hypervisor-initiated swapping because the guest OS has better knowledge of its own memory use. It knows which pages belong to inactive processes, caches, or other reclaimable structures.

Ballooning is not free of consequences. If the guest is already short on memory, balloon inflation may cause the guest OS to page internally. The workload can then slow down even though ESXi has avoided or reduced host-level swapping.

Ballooning example

During host memory pressure, the VMkernel sends a reclamation request to a VM. The vmmemctl driver inflates inside that VM, and the guest OS chooses memory to reclaim according to its normal policies. If the guest has enough inactive cache, the effect may be limited. If the guest is already busy, guest-level paging and application slowdown may occur.

Memory Compression

Memory compression stores selected memory pages in compressed form so that host RAM can hold more logical page content. ESXi memory compression is enabled by default on ESXi hosts.

When contention occurs, ESXi can compress suitable pages instead of immediately writing them to a VM swap file. If the page is needed again, ESXi decompresses it. Compression therefore attempts to avoid or reduce slower disk-based swap I/O.

The trade-off is CPU work. Compressing and decompressing pages consumes processor resources and adds processing latency. However, this cost is often lower than waiting for storage, so compression is positioned before relying solely on slower swap operations.

Compression example

When contention occurs before sustained disk swapping, ESXi may compress suitable pages in RAM. The host frees some usable physical memory, while the affected VM pays the CPU cost only when compressed pages are stored or retrieved.

Host-Level SSD Swapping

Host-level SSD swapping uses an SSD on the ESXi host for a host cache swap file. The cache is intended to improve swap-related operations compared with slower storage.

This mechanism is different from normal VM swap-file placement. A VM swap file is disk-backed storage used for a VM's memory pages when ESXi must swap. A host cache swap file is a host-level cache intended to improve the performance of swap-related access, potentially using SSD storage.

SSD swapping can reduce latency compared with slower disks, but it does not turn storage into RAM. It mitigates the consequences of memory pressure rather than eliminating them. A host that repeatedly needs SSD-backed swapping still has a memory-capacity or workload-placement problem to review.

SSD swapping example

On an SSD-equipped host, an administrator places the host cache swap file on SSD storage. If swap-related activity occurs, accesses may be faster than they would be on slower disks. The VMs can still experience performance degradation because SSD latency remains much higher than RAM latency.

ESXi Disk Swapping

Swapping moves memory pages from RAM to disk to free physical memory for other workloads. When ESXi must reclaim memory and other methods are insufficient, it writes VM memory pages to a VM swap file.

Disk swapping is the last-resort reclamation method because storage I/O is much slower than RAM access. A VM may need to wait for a page to be read back before an application can continue using it.

Symptoms of excessive swapping

• Elevated disk activity on the host or datastore.
• Increased storage latency.
• Slow VM response and application stalls.
• Reduced application throughput and longer transaction times.
• Performance degradation that becomes worse under sustained workload.

Persistent swapping usually indicates insufficient host memory, excessive memory overcommitment, or poorly balanced workloads. Adding RAM, moving VMs, reducing memory demand, or changing workload placement is generally more effective than treating continuous swapping as normal operation.

Comparing ESXi Memory Reclamation Technologies

Technology | What it does | Where it operates | Key dependency | Primary benefit | Performance impact

Transparent Page Sharing | Shares one physical copy of identical pages. | Host and VMkernel memory mapping. | Identical page contents. | Reduces duplicated physical RAM use. | Usually low for the guest; sharing is limited when pages differ.

Ballooning | Requests the guest to release less-active memory. | Guest-assisted interaction with the VMkernel. | VMware Tools and a functioning vmmemctl driver. | Uses guest OS knowledge to reclaim memory before hypervisor swapping. | Can cause guest paging if the guest is already short on memory.

Memory compression | Stores selected pages in compressed form in host RAM. | ESXi host memory. | CPU capacity and compressible pages. | Avoids or reduces some VM swap-file writes. | Uses CPU and adds compression or decompression work.

Host-level SSD swapping | Uses an SSD-backed host cache swap file for swap-related access. | ESXi host storage and cache. | Suitable SSD storage and configuration. | Improves swap-related latency compared with slower storage. | Still slower than RAM; mitigates rather than removes memory pressure.

Swapping | Writes VM memory pages to a VM swap file. | ESXi host and backing storage. | Available datastore storage. | Frees physical RAM when other methods cannot meet demand. | Highest cost; storage latency can severely reduce VM performance.

The central operational goal is to avoid sustained disk swapping. TPS, ballooning, compression, and SSD-backed caching can each reduce the amount or cost of physical-memory reclamation, but none removes the need to size hosts for expected active demand.

Memory Pressure Symptoms and Likely Causes

Observed symptom | Likely memory condition | Technology involved | Likely operational response

Ballooning is active | The VMkernel is reclaiming memory through a guest driver. | Ballooning and vmmemctl. | Verify VMware Tools, check guest paging, and assess host memory capacity.

Compression is active | The host is under contention and is preserving pages in compressed form. | Memory compression. | Monitor CPU overhead and memory demand; investigate recurring contention.

Host cache swap use increases | The host is using SSD-backed swap caching to handle memory pressure. | Host-level SSD swapping. | Treat the SSD as mitigation and review capacity and workload placement.

VM swap activity increases | ESXi is writing VM memory pages to a VM swap file. | Disk swapping. | Check storage latency and reduce memory pressure urgently.

VMs become slow under load | Active demand may exceed available physical RAM, or the guest may be paging. | Ballooning, compression, SSD swapping, or disk swapping. | Correlate host reclamation, guest paging, active memory, and storage performance.

Operational Guidance for Memory Overcommitment

When overcommitment is useful

Memory overcommitment can improve consolidation when VM demand varies over time. For example, development VMs, lightly used services, or workloads with different peak periods may not require their configured memory simultaneously.

When overcommitment is dangerous

Aggressive overcommitment is risky for databases, analytics systems, high-throughput applications, and latency-sensitive services that use large amounts of memory continuously. If several such VMs peak together, reclamation can become persistent.

• Maintain adequate physical RAM for expected active demand and growth.
• Install and maintain VMware Tools so ballooning can work effectively.
• Monitor host memory contention before users report sustained slowdown.
• Correlate ballooning and compression with guest paging and application performance.
• Investigate host cache swap and VM swap activity rather than accepting it as routine.
• Balance memory-intensive VMs across hosts where possible.
• Use SSD-backed host cache as a mitigation, not as a replacement for host RAM.

For broader administration context, review the VMware ESXi online course and related topics such as vSphere alarms for monitoring and operational response.

Troubleshooting Memory Reclamation

A VM cannot participate effectively in ballooning

Likely causes include VMware Tools not being installed, VMware Tools not running, or an unavailable or malfunctioning vmmemctl driver.

1. Verify VMware Tools status inside the guest.
2. Verify that the vmmemctl balloon driver is present and functioning.
3. Check whether the ESXi host is experiencing memory contention.
4. Restore VMware Tools functionality, then reassess host pressure.
5. If contention continues, review host capacity and workload placement.

VM responsiveness is poor and storage latency rises

ESXi may be swapping because the host does not have enough physical RAM, memory overcommitment is too aggressive, or too many memory-intensive VMs are concentrated on one host.

1. Check host and VM swap activity together with datastore and device latency.
2. Compare active memory demand with available host RAM.
3. Identify the VMs contributing the most active memory during the incident.
4. Add RAM, move workloads, or reduce VM memory demand as appropriate.
5. Use SSD-backed host cache where suitable, while treating it as mitigation only.

Ballooning slows a guest workload

The guest may already be under memory pressure. Balloon inflation can cause the guest OS to page internally, so both guest paging and host reclamation must be evaluated.

Determine whether the VM needs more memory or whether host-level overcommitment must be reduced. Correct the underlying guest or host shortfall instead of relying on ongoing ballooning.

Compression and swap mechanisms are repeatedly active

Repeated activity usually indicates sustained host memory contention or insufficient capacity for the workload profile.

1. Identify peak-demand periods and the VMs driving active memory use.
2. Check whether memory-intensive workloads are concentrated on one host.
3. Rebalance workloads, increase host RAM, or revise overcommitment assumptions.

Exam-Relevant Notes

• VMkernel: manages host hardware resources, including physical memory.
• TPS: shares identical physical pages and is transparent to the guest allocation.
• Ballooning: is guest-assisted and depends on VMware Tools and vmmemctl.
• Compression: uses CPU to keep selected pages compressed in RAM and avoid some disk writes; it is enabled by default on ESXi hosts.
• Host-level SSD swapping: uses an SSD-backed host cache swap file and is distinct from ordinary VM swap-file placement.
• Swapping: writes VM memory pages to a VM swap file and has the greatest performance cost.
• These mechanisms are complementary, but sustained reclamation—especially VM swapping—is a signal to review capacity, workload placement, and overcommitment.