VMware ESXi and vSphere Cluster Management
VMware ESXi Memory Management Technologies
Learn how the ESXi VMkernel manages host RAM through TPS, ballooning, compression, SSD host cache, and swapping under memory pressure.
ESXi can run many virtual machines (VMs) on one physical host, but every VM ultimately needs backing from the host's physical RAM. The ESXi VMkernel is the hypervisor component that manages this resource. When demand exceeds readily available RAM, it uses several reclamation technologies to make memory available while limiting performance impact.
This lesson explains memory overcommitment, Transparent Page Sharing (TPS), ballooning, memory compression, host-level SSD swapping, and hypervisor swapping. It also shows how to distinguish these mechanisms in performance data and how to respond to memory pressure.
VMkernel memory management overview
A host has a finite amount of host physical RAM. A VM, however, is presented with a virtual hardware configuration that includes a specified amount of memory. The VM sees that memory as its own RAM, while the VMkernel maps the VM's guest-physical pages to locations in host physical memory or, when necessary, to other backing mechanisms.
Configured VM memory is not the same as memory actively being used. For example, a VM configured with 16 GB may currently have a working set—the pages it is actively using—of only 6 GB. Across many VMs, configured memory and current demand can both exceed the host's installed RAM. This is called memory overcommitment.
Memory overcommitment is useful because workloads often peak at different times. A host may consolidate more VMs than would fit if every configured byte had to remain resident in RAM at all times. Overcommitment is not automatically harmful. The risk begins when demand remains higher than the host's readily available physical memory. That condition is memory contention.
During contention, the VMkernel attempts to reclaim memory in ways that preserve VM performance as far as possible. It may avoid storing duplicate pages, ask a guest operating system to release memory, compress selected pages in RAM, use an SSD-backed host cache, or swap pages to storage. These methods are related, but they do not have identical costs or prerequisites.
Memory overcommitment
Memory overcommitment means that the aggregate VM memory allocation or active demand is greater than the host's immediately available physical RAM. It can improve consolidation ratios when several VMs have non-overlapping workload peaks. For example, a development VM may be idle during business hours while a reporting VM is busy, allowing their host memory demand to share capacity.
Overcommitment requires measurement. Before increasing VM density, review active memory, consumed memory, the host memory state, ballooned memory, compressed memory, swap-in and swap-out activity, guest paging, and application latency. A host with high configured memory but low active demand may be healthy; a host with sustained reclamation and slow applications is not.
VM memory allocation is also a sizing decision. A VM configured with substantially more RAM and vCPUs than its workload uses consumes consolidation flexibility. Measure the workload before reducing or increasing its allocation. Do not treat reclamation mechanisms as a replacement for adequate capacity.
Transparent Page Sharing (TPS)
Transparent Page Sharing (TPS) is a memory-page deduplication mechanism. The VMkernel identifies pages with matching contents and allows multiple VMs to reference one physical page instead of keeping duplicate copies.
TPS can reduce physical-memory consumption before severe contention occurs. Its benefit depends on workload similarity. Several VMs built from similar guest operating-system images and application components may contain many identical pages. Different applications, patches, encryption, and changing runtime data reduce the opportunity for sharing.
Shared pages use copy-on-write semantics. Copy-on-write means that a VM can continue reading a shared page, but when it changes the page, the VMkernel creates a private copy for that VM. The original shared page remains available to other VMs.
TPS behavior and savings vary by ESXi release, security settings, page-sharing salting configuration, and workload. Some configurations restrict sharing between VMs or change when scanning occurs. Therefore, TPS should be treated as an opportunistic saving rather than guaranteed capacity. Plan host RAM using measured demand, not an assumed TPS ratio.
Example: similar guest workloads
Suppose several VMs run comparable guest operating systems and application components. Many pages may contain the same code or read-only data, so TPS can represent those pages once in host RAM. If one VM modifies a shared page, copy-on-write gives that VM a private version. The actual saving depends on how much content remains identical and on the ESXi security and configuration policy.
Ballooning
Ballooning is cooperative guest-memory reclamation requested by the VMkernel. It depends on VMware Tools, guest integration software that includes virtualization-aware components, including the vmmemctl balloon driver in supported guest operating systems.
- The VMkernel detects host memory contention and selects a VM from which memory can be reclaimed.
- It signals the vmmemctl driver inside that guest.
- The balloon driver allocates memory inside the guest operating system.
- The guest OS responds using its own memory-management policy. It may release cache pages or page less-used pages to its virtual disk.
- The VMkernel can reclaim the corresponding host-physical backing memory for another workload.
Ballooning is generally preferable to hypervisor swapping because the guest OS understands its own page use. It can select pages that are less valuable to applications, whereas the hypervisor has less visibility into guest-level meaning. Ballooning is not free: if the guest becomes constrained, guest paging can increase and application response time can suffer.
If VMware Tools is absent, stopped, incompatible, unhealthy, or unable to load vmmemctl, the VM cannot participate effectively in cooperative reclamation. Under pressure, the VMkernel may rely more heavily on compression or swapping. Ballooning metrics must therefore be interpreted with guest paging and application latency, not in isolation.
Example: healthy balloon driver
A host becomes memory constrained and signals vmmemctl in a VM that has reclaimable memory. The balloon driver allocates guest memory, prompting the guest OS to discard cache or page less-used data. The host then reuses the reclaimed RAM. If the guest begins paging heavily, the administrator should investigate whether the host shortage is persistent and whether the VM is correctly sized.
Memory compression
Memory compression stores selected reclaimed pages in compressed form in host RAM. ESXi enables memory compression by default. Compression is an intermediate technique intended to avoid or reduce disk-based swapping during contention.
For example, if a reclaimable page compresses to half its original size, ESXi may retain that compressed representation in RAM rather than immediately writing the page to swap storage. This consumes CPU for compression and decompression, but avoiding storage I/O often produces better application latency than retrieving the page from disk.
Compression is most useful when pages compress effectively and CPU capacity is available. Its capacity is finite, and compressed data still occupies host RAM. Persistent or severe contention can exhaust compression space and lead to host swapping.
Host-level SSD swapping
Host-level SSD swapping uses a solid-state device for host cache swap activity. An SSD-backed host cache is distinct from ordinary VM swap files and from guest operating-system swap or page files.
When a reclaimed page must be stored outside host RAM, an SSD-backed host cache can reduce access latency compared with conventional disk-backed swap storage. This may reduce the impact of unavoidable swap-in and swap-out operations, but it does not make swapping equivalent to RAM.
Plan host cache with attention to device capacity, write endurance, sustained performance, connectivity, and placement. Confirm that the device and configuration are supported by the installed ESXi version. Document the configuration and monitor it after deployment. An SSD host cache is a mitigation, not a substitute for sufficient host memory.
Hypervisor swapping
Host swapping, also called ESXi or hypervisor swapping, moves VM memory pages from host RAM to disk-backed swap storage so the physical RAM can be used elsewhere. The storage may be associated with a VM swap file or another supported swap location.
Among the mechanisms discussed here, conventional host swapping is generally the most expensive because storage I/O has much higher latency than RAM. Frequent swap-in and swap-out can cause application slowdowns, elevated latency, and poor VM responsiveness. A brief event may be harmless, but sustained activity is a reason to investigate capacity and placement.
Host swapping is not the same as guest paging. In host swapping, ESXi decides which VM memory pages to move and manages the backing storage. In guest paging, the guest operating system decides which of its pages to move to its virtual disk.
How the mechanisms relate under pressure
These technologies should be understood as complementary mechanisms rather than unrelated features. Page sharing can reduce duplicate consumption before severe pressure. Ballooning requests cooperative reclamation from the guest. Compression attempts to keep reclaimed pages in RAM in a smaller form. An SSD-backed host cache can reduce the latency of host-level swap access. Conventional disk swapping remains a costly fallback when memory demand persists.
This is a conceptual relationship, not an unchanging universal sequence. Exact policy and behavior depend on the ESXi release, configuration, security settings, workload, and current resource state. As reclamation becomes more aggressive, the risk of guest paging, storage latency, CPU overhead, and application impact generally increases.
| Technology | Primary mechanism | Where it operates | Dependency or prerequisite | Benefit | Main cost or limitation | Typical operational signal |
|---|---|---|---|---|---|---|
| Transparent Page Sharing | Deduplicates identical page contents | VMkernel and host RAM | Shareable page contents and permitted TPS behavior | Reduces duplicate physical-memory use | Savings vary with workload, release, security, and salting configuration | Shared memory or reduced backing demand |
| Ballooning | Guest cooperatively allocates memory for reclamation | Guest OS and VMkernel | Working VMware Tools and vmmemctl driver | Lets the guest choose less valuable pages | Can cause guest paging and application impact | Ballooned memory and possible guest paging |
| Memory compression | Retains selected pages in compressed form | VMkernel and host RAM | Available compression capacity and CPU | Can avoid disk I/O | Uses CPU; capacity is finite | Compressed memory |
| Host-level SSD swapping | Uses SSD-backed host cache for swap activity | VMkernel and SSD device | Supported, suitable SSD and configured host cache | Lower swap access latency than conventional disk | Still slower than RAM; consumes capacity and endurance | Host cache use and swap I/O |
| Hypervisor swapping | Moves VM pages to disk-backed swap storage | VMkernel and storage | Swap storage and sufficient I/O capacity | Frees host RAM when other methods are insufficient | High latency and possible severe VM slowdown | Swap-in, swap-out, and storage latency |
Monitoring ESXi memory behavior
Use the vSphere Client's host and VM performance views to examine memory usage, active memory, consumed memory, shared memory, ballooned memory, compressed memory, swapping, and host memory-state indicators. Metric names and available counters differ across vSphere versions and interfaces, so confirm the meaning of a counter in the version being monitored.
Active memory is an estimate of the pages actively used by a VM. It is useful for evaluating working-set demand, but it is not a perfect measure of every important memory need. Compare it with configured memory, guest free memory, guest paging, application behavior, and the time interval selected.
Use esxtop memory views to inspect host and per-VM behavior. Review the displayed fields before drawing conclusions, because field names and interpretation depend on the view and ESXi version. Use esxcli commands appropriate to the installed version to inspect host configuration and storage resources; do not apply command syntax from a different release without verification.
Always correlate vCenter or ESXi statistics with guest OS telemetry and application metrics. A high balloon value with no guest paging may be tolerable; the same value with sustained page-file activity and rising request latency indicates a more serious shortage.
Host memory pressure troubleshooting matrix
| Observed symptom or metric | Likely interpretation | Checks to perform | Recommended response |
|---|---|---|---|
| High ballooned memory | ESXi is reclaiming memory cooperatively | Check guest paging, active memory, application latency, and VMware Tools health | Reduce contention, right-size VMs, migrate workloads, or add RAM if sustained |
| Guest paging during ballooning | The guest is under pressure after reclamation | Compare page-file activity, configured RAM, active working set, and workload demand | Provide justified VM memory, reduce workload demand, or relieve host contention |
| High compressed memory | ESXi is using RAM to avoid some disk operations | Check CPU overhead, compression trend, host memory state, and swap activity | Investigate persistent demand and expand or rebalance capacity |
| Swap-in or swap-out activity | VM pages are being moved through host-level swap | Confirm whether activity is sustained; check storage latency, active memory, ballooning, and compression | Migrate VMs, add RAM, right-size allocations, and address storage performance |
| Slow storage during swapping | Swap I/O is adding substantial latency | Check datastore or host-cache latency, device saturation, placement, and endurance | Improve storage or host-cache placement while correcting the underlying memory shortage |
| No ballooning where expected | The guest may not be able to cooperate, or contention may not be present | Verify VMware Tools, vmmemctl, guest service and driver state, policies, and host memory state | Repair supported Tools installation and reduce pressure; do not disable ballooning as a default fix |
Guest paging versus ESXi swapping
| Characteristic | Guest OS paging | ESXi host-level swapping |
|---|---|---|
| Decision maker | The guest operating system | The ESXi VMkernel |
| Storage destination | The guest's virtual disk or page-file storage | ESXi swap storage, such as a VM swap file or supported host location |
| Typical visibility | Guest OS counters, logs, and application monitoring | vSphere or esxtop swap counters and host storage metrics |
| Performance implication | Can slow the guest, especially with sustained paging | Can cause high latency because ESXi must retrieve VM pages from storage |
| Administrative response | Investigate guest sizing, workload, page-file use, and guest configuration | Investigate host contention, VM placement, capacity, swap storage, and right-sizing |
Practical diagnosis scenarios
Applications are slow and ESXi reports swap activity
- Confirm whether swap-in and swap-out are sustained rather than a brief event.
- Check host memory contention, active-memory demand, compression, ballooning, and datastore or host-cache latency.
- Check guest paging and application latency to determine where the workload is affected.
- Migrate or rebalance VMs, add physical RAM or another suitably sized host, and right-size VM memory based on measured demand.
- If swapping cannot be avoided immediately, address storage performance and use a suitable supported host-cache design where appropriate.
Ballooning is absent or ineffective
Confirm that VMware Tools is installed and running, then verify that the guest can load and use vmmemctl. Check guest logs, service state, driver compatibility, and administrative policies. Also confirm that the host is actually under contention. Repair, update, or reinstall VMware Tools using supported procedures, correct guest-side issues, and reduce host pressure while cooperative reclamation is restored.
High balloon values coincide with poor guest performance
Determine whether the guest is paging heavily after memory is reclaimed. Compare configured RAM, active working set, guest page-file activity, and application behavior. If demand is persistent, provide more memory where justified, reduce workload demand, migrate VMs, or expand capacity. Do not assume ballooning alone is the root cause; it may be exposing an underlying host shortage.
Expected TPS savings are minimal
Assess whether the VMs truly have similar memory contents. Review release-specific TPS and security behavior, workload diversity, guest updates, encryption, and other factors that reduce page similarity. Treat TPS as an opportunistic saving, plan with actual demand measurements, and use configuration practices appropriate to the environment's security requirements.
Capacity-management practices
- Add capacity: Install more host RAM or add another suitably sized host when contention is persistent.
- Rebalance workloads: Migrate or redistribute VMs so demand is not concentrated on one host.
- Right-size VMs: Reduce unnecessary RAM allocations only after reviewing active memory, guest behavior, and application requirements.
- Measure working sets: Use active memory together with guest and application telemetry rather than relying on configured memory alone.
- Validate VMware Tools: Keep supported guest integration software healthy so ballooning can operate when needed.
- Protect storage: Monitor datastore and host-cache latency, capacity, endurance, and performance when swap activity occurs.
- Investigate before changing settings: Do not disable ballooning or depend on SSD swapping as a default performance fix. Find the workload or capacity cause first.
Relationship to vSMP and VM sizing
vSMP means virtual symmetric multiprocessing: assigning more than one virtual CPU to a VM. It is primarily a CPU-sizing concept, not an ESXi memory-reclamation technology.
Even so, multi-vCPU VMs often support larger or more parallel workloads and may also be configured with larger memory allocations. Consider vCPU count and RAM together when right-sizing a VM. An oversized VM can reduce consolidation flexibility even when its workload uses only a fraction of its assigned resources.
Exam-relevant notes
- TPS deduplicates identical pages; copy-on-write creates a private page when a VM modifies a shared page.
- Ballooning is cooperative reclamation through VMware Tools and the vmmemctl driver.
- Compression keeps selected pages in compressed host RAM and trades CPU work for reduced storage I/O.
- SSD host cache can make host swap access faster than conventional disk, but it does not replace physical RAM.
- ESXi host swapping is distinct from paging performed by a guest operating system.
- Sustained swap-in, swap-out, guest paging, or high latency indicates a capacity or workload-placement problem that should be investigated.
- Exact reclamation behavior depends on ESXi release, configuration, security settings, and workload; do not memorize an absolute order as universal policy.
- vSMP concerns virtual CPUs and should not be classified as a memory-reclamation mechanism.
For continued study, use the memory management technologies reference alongside version-specific vSphere documentation and measured host and guest performance data.