VMware memory ballooning and ESXi swapping: how vSphere memory overcommit reclaims memory

How ESX reclaims memory when vSphere memory is overcommitted

When the VMs on a host need more memory than the host holds, vSphere memory is overcommitted and ESX reclaims memory from the VMs. Broadcom’s Performance Best Practices for vSphere 9.0 (revision 20250731) list five mechanisms for this: page sharing, ballooning, memory compression, swap to host cache and regular swapping. The last four come into play in that order as host memory runs short. Some ballooning is “quite normal and not indicative of a problem”, as the same guide puts it. Sustained ballooning and host swapping usually mean that the active memory of the VMs does not fit in the host’s physical memory, or that a memory limit holds a VM below what it asks for.

Overcommitment in Broadcom’s sense is about working memory, not configured memory. The vSphere 9.1 documentation (29 September 2026) says the configured memory of all VMs “may exceed the amount of available physical memory on the ESX host”, which “doesn’t necessarily mean memory is overcommitted”. Broadcom ties overcommitment to “the combined working memory footprint of all virtual machines” exceeding the host’s memory.

Performance Best Practices for VMware vSphere 9.0 (revision 20250731); Broadcom TechDocs vSphere 8.0 and 9.1 Resource Management (16 to 29 September 2026), Memory Tiering considerations (12 October 2026); KB 374743.

Free memory states in esxtop: high, clear, soft, hard and low

The esxtop memory panel shows the host’s state on the VMKMEM line. The esxtop documentation of the panel for vSphere 8.0 (16 September 2026) and 9.1 (12 October 2026) reads “Possible values are high, soft, hard and low” and “High means that the machine memory is not under any pressure and low means that it is.” Broadcom’s KB 374743, written for ESXi 7.0 and 8.0, lists a fifth state and the order: “High state > Clear state > Soft State > Hard State > Low State”.

We found no current Broadcom document that publishes the amount of free memory at which a host moves from one state to the next, or that ties each technique to a state. The vSphere 8.0 chart documentation gives two host-level figures instead: consistently high memory usage of 94% or greater means the host is probably short of memory, and “A free memory value of 6% or less indicates that the host cannot handle the demand for memory”, which leads to reclamation.

The state is a host value, and a VM can be reclaimed while the host shows high. KB 374743 describes hosts with swap-in and swap-out rates above zero, low overall memory use and a high state, and gives the cause as a configured memory limit: ESXi swaps “when it cannot satisfy the amount of memory requested by a virtual machine due to specifically configured memory limit.”

Transparent page sharing and salting

ESX can keep one copy of memory pages with identical content, but by default it does so only inside a VM, a default that vSphere 6.0 introduced and patches brought to some earlier releases. Broadcom’s KB 323624 explains the mechanism. A VM’s salt is its unique vc.uuid unless set otherwise, and pages are shared only between VMs with the same salt, so cross-VM sharing needs a common salt per VM or a change to the host setting Mem.ShareForceSalting, which defaults to 2. The vSphere 9.1 documentation gives the reason: “Due to security concerns, inter-virtual machine transparent page sharing is deactivated by default”.

Re-enabling sharing between VMs is a security decision that applies to the whole host. Per the 9.0 best practices, ESX does not share large pages, so on a host that uses them, savings may appear only once memory pressure makes ESX break large pages into small ones.

Ballooning, compression and host swapping

Ballooning works through vmmemctl, a driver installed with VMware Tools. When ESX sets a balloon target, the driver allocates memory inside the guest, so the guest operating system frees the pages it needs least and pages them out to its own virtual disk if it has to. For that reason Broadcom asks, on overcommitted hosts, for guest swap space of at least the VM’s configured memory minus its reservation. The vSphere 8.0 chart documentation calls the driver “critical to performance” and asks you to verify that it is enabled. The VM option sched.mem.maxmemctl caps how much ballooning can reclaim from one VM, in MB.

Compression, on by default, comes before host swapping. A page chosen for swap-out that compresses to 2 KB or less goes into a compression cache in memory instead of to disk. The best practices explain that “the decompression latency is much smaller than the swap-in latency”. Pages that do not compress go to the VM’s own swap file, and the guest is not involved.

The 9.0 best practices advise against overcommitting memory to the point where host swapping swaps out active pages, and against turning off the earlier techniques: “Because ESX uses page sharing, ballooning, and memory compression to reduce the need for host-level memory swapping, don’t deactivate these techniques.”

esxtop memory counters and vCenter charts

In esxtop on the host, press m for the memory panel. The PMEM, VMKMEM, PSHARE, SWAP, ZIP and MEMCTL lines summarise the host, and each VM row carries the per-VM counters, all in MB or MB per second. Columns that are not on screen are added with f.

Broadcom TechDocs: esxtop memory panel, vSphere 8.0 (16 September 2026) and 9.1 (12 October 2026); KB 438023 (ESXi 8.0) and KB 374743 (ESXi 7.0 and 8.0).

KB 438023 states that “The goal is sustained zero swap activity.” SWCUR alone can mislead, since KB 374743 notes that swapped pages return gradually; the rates show whether a VM is still waiting for pages from disk. The CPU side of the same host, ready time and co-stop, is covered in our guide to CPU ready and the vCPU ratio.

In vCenter, the best practices read Ballooned memory (Average) under Monitor, Performance, Advanced, Memory; an absence of ballooning suggests that ESX is not under heavy memory pressure. Where Consumed is higher than Active in the same chart, they read it as the guest “currently getting all the memory it requires”. Under Monitor, Utilization, Guest Memory, non-zero Swapped and Compressed values are “a sign of more significant memory pressure”. The cluster counters Balloon and Consumed are collected at statistics level 1, Active and Swap Used only from level 2.

Our infrastructure audit maps hosts, clusters and their actual resource usage from the exports you provide. Send us the esxtop memory lines of a host that balloons or swaps, with the limits and reservations of its VMs.

Common causes of ballooning and swapping

Memory limits come first because they cause swapping on hosts with memory to spare. A limit is a VM setting, sched.mem.max in the .vmx file, and KB 374743 resolves the case by setting it to Unlimited and reloading the VMX file.

Reservations work the other way. Reserving a VM’s entire memory eliminates host swapping for that VM, but the 9.0 best practices warn that reservations reduce the number of VMs a system can run. The vSphere 8.0 documentation advises lowering a reservation set “much higher than its active memory” so that the VMkernel can reclaim idle memory for other VMs.

Oversized VMs inflate consumed memory. KB 438023 reads a consistently low ratio of active to allocated memory as a sign of oversizing, and the best practices note that over-allocating memory increases the VM’s memory overhead. Measuring and cutting oversized VMs is the subject of our guide to waste in a vSphere estate.

HA failover capacity shows its effect only when a host fails. Broadcom’s vSphere 8.0 HA admission control page counts reserved memory and says “The actual memory consumed by the virtual machine is not considered in the calculation”, and where usage exceeds reservations, “insufficient failover capacity is available, resulting in performance degradation on failover.” A cluster of 12 hosts that passes admission control can still balloon and swap on the remaining 11; our guide to host consolidation under per-core licensing sizes clusters with one host down.

On ESX 9 hosts, Memory Tiering adds NVMe capacity behind DRAM. Broadcom’s 9.1 guidance, updated on 12 October 2026, states “Do not use memory overcommit when Memory Tiering is activated.” It also notes that swap code “uses simplistic random selection of pages to swap out”, while tiering ages pages into hot and cold. Requirements and sizing are in our guide to vSphere Memory Tiering with NVMe.

How to fix memory ballooning and swapping in vSphere

Work from the host to the VM, one change per maintenance window, so that each step shows its effect.

1. Capture the slow period in esxtop with m: the state on the VMKMEM line, MCTLSZ, SWR/s and SWW/s per VM, and whether the host is reclaiming at all.
2. If a VM swaps on a host in the high state, check its memory limit and set it to Unlimited unless its owner confirms the reason for it.
3. Check MCTL? for every VM and install or repair VMware Tools where it shows N.
4. Compare active and consumed memory per VM over 30 days and reduce oversized VMs in steps, each needing a power-off.
5. Lower reservations that sit far above active memory, and reserve the full memory only of VMs that must never be swapped.
6. Move load with DRS or vMotion to hosts with spare memory, and add physical memory where the cluster’s active memory does not fit with one host down.
7. Check swap inside the guest, since KB 438023 reads active in-guest paging as a VM undersized for its workload, which the host cannot see.

Memory overcommit in capacity planning

Memory often sets the number of hosts a cluster needs, and memory carries no VMware licence, while every host adds licensed cores. Size the cluster so that the 95th percentile of consumed memory fits the hosts that remain after a failure, at a utilisation ceiling you accept. The chart figures of 94% usage and 6% free memory describe a host that is already short of memory, so the ceiling belongs below them. Treat sustained ballooning or any swap-in at the monthly peak as a finding. The three-year forecast is in our guide to vSphere capacity planning.

If the memory data allow fewer or larger hosts, our engineering partner Vixen.UNO consolidates the clusters under VMware optimisation, in agreed maintenance windows with a rollback plan. Describe your clusters and their memory per host.

What we do

For memory problems, VMware optimisation begins with the estate and licence audit, in which the Vixen.UNO team records the actual resource usage of every host and cluster next to versions and subscriptions. The same team then matches editions and subscriptions to your actual workloads and consolidates hosts and clusters, and if there is nothing to optimise, we say so. Eurokommerz holds the contract and supplies hardware and licences. Changes run in agreed maintenance windows, step by step, with a rollback plan at every stage, and support under an agreed SLA can follow. Our infrastructure audit works from the documentation and exports you provide, without access to your production systems. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ