vSphere memory reclamation cascade: balloon to compress to swap in minutes

Hosts can sit at 75% consumed memory for hours with zero reclamation activity. A workload spike, a large VM power-on, or a memory leak can push consumed memory past physical capacity in minutes. ESXi’s response is not graceful: balloon inflates across VMs, compression activates, .vswp files open on the production datastore, swap-in begins, and datastore latency rises as swap I/O competes with VM disk I/O. By the time swap-in rate is above zero, the host has exhausted every gentler mechanism and is reading VM memory pages back from disk. That is a production emergency, not a tuning exercise.

What this means

ESXi reclaims memory in a defined order when host free memory drops below its threshold:

1. Transparent Page Sharing (TPS) - deduplicates identical pages. Inter-VM TPS is disabled by default since vSphere 6.0 for security, so this tier is not a factor on most clusters under new pressure.
2. Ballooning - the vmmemctl driver inside the guest is inflated, forcing the guest OS to reclaim pages through its own memory manager. Guest-aware but slow; the guest’s internal paging is invisible to ESXi.
3. Compression - pages are compressed into the per-VM compression cache. Avoids disk I/O but consumes CPU and adds latency on every access. The cache has a fixed size; when full, swapping begins.
4. Host-level swapping - VM memory pages are written directly to .vswp files on the datastore. No guest involvement. Catastrophically slow, and the host is blind to which pages are active.

The signature of the cascade is the sequence: balloon first (MCTLSZ rising from zero), then compression (ZIP/s rising), then swap-out (SWW/s rising), then swap-in (SWR/s rising). If you see swap with zero balloon, an assumption is broken: VMware Tools is not running, or the balloon driver is disabled, and the host has skipped directly to swap. That is worse than the raw numbers suggest because the host has no guest-aware reclamation available.

The death spiral forms once swapping is active: swap I/O competes with VM disk I/O on the same datastore, datastore latency rises, applications slow down, in-flight operations hold memory longer, and the host’s pressure gets worse instead of better.

flowchart TD
    A[Consumed nears physical RAM] --> B[Balloon inflates, MCTLSZ rises]
    B --> C{Balloon sufficient?}
    C -- No --> D[Compression, ZIP/s rises, cache fills]
    D --> E{Compression sufficient?}
    E -- No --> F[Swap-out, SWW/s rises, pages to .vswp]
    F --> G[Swap-in, SWR/s rises, active degradation]
    G --> H[.vswp I/O competes, KAVG rises]
    H --> I[Apps slow, ops hold memory longer]
    I --> A

Common causes

Quick checks

# Identify which VMs are being swapped and ballooned right now (ESXi host shell via SSH)
esxtop
# Press 'm' for memory view
# Press 'f' to field-select MCTLSZ, MCTLTGT, SWCUR, SWW/s, SWR/s if not visible
# Sort by SWCUR (current swap usage) to find the worst offenders
# Then sort by MCTLSZ (balloon current) to see who is being squeezed

# PowerCLI: list ballooned and swapped VMs across vCenter
Get-VM | Select Name,
  @{N='BalloonedMB';E={$_.ExtensionData.Summary.QuickStats.BalloonedMemory}},
  @{N='SwappedMB';E={$_.ExtensionData.Summary.QuickStats.SwappedMemory}}

# Check VMware Tools status on every VM (Tools not running = no ballooning possible)
Get-VM | Select Name,
  @{N='ToolsStatus';E={$_.ExtensionData.Guest.ToolsRunningStatus}}

# Distinguish cascade from storage array problem: KAVG vs DAVG
esxtop
# Press 'u' for disk device view
# High KAVG + moderate DAVG = .vswp I/O contention inside the VMkernel, not array problem
# High DAVG + low KAVG = genuine array problem

# Check .vswp files on a datastore
ls -lh /vmfs/volumes/<datastore>/*/*.vswp

How to diagnose it

1. Confirm the cascade is active. Open esxtop memory view on the affected host. Look for non-zero MCTLSZ across multiple VMs, non-zero ZIP/s, and non-zero SWCUR. Non-zero SWR/s (swap-in) confirms active degradation, not just proactive swap-out.

2. Identify the memory consumers. Sort esxtop memory view by SWCUR and MCTLSZ. The VMs with the largest swap and balloon footprints are the victims. The VM with the largest active memory growth is often the cause.

3. Confirm VMware Tools is running on victim VMs. If SWCUR is non-zero but MCTLSZ is zero, Tools is not running or the balloon driver is disabled. The host skipped directly to swap. The numbers understate the damage because guest-aware reclamation was never attempted.

4. Distinguish cascade from storage array problem. Open esxtop disk device view (press ‘u’). Elevated KAVG with normal DAVG means the latency is from .vswp I/O queuing inside the VMkernel, not from the array. Elevated DAVG with KAVG following means the array is the source. This determines whether you page the storage team or the virtualization team first.

5. Check cluster balance. Compare per-host consumed memory across the cluster. If other hosts have headroom and DRS did not move VMs, check DRS mode, recent migration failures, and affinity rules blocking rebalance.

6. Look for the trigger. Check recent events: VM power-ons, memory limit changes, snapshot consolidations, host exits from maintenance mode. The cascade often starts at a specific moment with a specific cause.

Metrics and signals to monitor

Fixes

Stop the active spiral first

The immediate goal is to break the swap-in feedback loop. Do not try to tune memory settings while the host is actively swapping in pages.

vMotion VMs off the host. If other hosts have headroom, migrate VMs off the pressured host. Consumed memory drops below the reclamation threshold, and the cascade relaxes within minutes as pages are reclaimed from .vswp. Fastest, safest first response. Brief stun during vMotion switchover.

Suspend or power off non-critical VMs. If vMotion is not available or other hosts are also constrained, suspending low-priority VMs releases their memory immediately. Destructive to those workloads.

Identify and address the leaker. If a single VM is consuming disproportionate memory, restart or migrate it. A memory leak will not self-correct and will continue to push the host deeper into the cascade.

Fix the root cause once stable

After the host is no longer swapping in pages:

Right-size VMs based on active memory. If the cluster is systemically overcommitted, reduce configured memory on VMs that have more than they actively use. Target active memory, not configured.

Set memory reservations on latency-sensitive VMs. A reservation exempts the reserved amount from ballooning. Use sparingly: reservations reduce the host’s flexibility to reclaim elsewhere. Reserve for databases and workloads where ballooning the buffer cache causes severe degradation.

Check for forgotten memory limits. A memory limit forces ballooning and swapping inside that VM even if the host has free physical RAM. This is one of the most insidious misconfigurations in vSphere. Remove limits unless intentional and documented.

Add host memory. If the cluster is genuinely undersized, the only durable fix is more physical RAM or more hosts. Aim for 20-30% headroom above total VM active memory, accounting for N+1 host failure.

DRS and cluster-level prevention

Verify DRS is enabled and in automatic mode. DRS evaluates placement every 5 minutes by default. Manual mode or disabled DRS means memory imbalance goes uncorrected.

Check DRS constraints. VM-VM and VM-Host affinity/anti-affinity rules can prevent DRS from migrating the VMs that would relieve pressure. A host that looks like it should be rebalanced but is not is often rule-constrained.

Verify HA admission control is not the silent blocker. Admission control reserves failover capacity. If configured aggressively, it can block new power-ons and leave existing hosts overcommitted while reserved capacity sits unused elsewhere.

Prevention

• Track consumed memory per host, not cluster averages. Cluster averages hide the one host at 95% while others sit at 60%.
• Track active vs consumed memory per VM. A VM with 64 GB configured and 8 GB active is a right-sizing candidate. Host headroom should be measured against total active memory, not configured.
• Alert on balloon target, not just balloon current. MCTLTGT shows intent. If the host wants to balloon but cannot (Tools not running), MCTLSZ stays at zero while MCTLTGT is non-zero. This is the silent skip-to-swap failure mode.
• Alert on any sustained swap-in. Swap-in above zero for more than 60 seconds in production is a paging emergency by definition. Do not wait for user complaints.
• Verify VMware Tools is running on every VM. Without Tools, the balloon driver cannot function. Audit Tools status regularly, especially after template deployments and guest OS patches.
• Reserve memory for databases and latency-sensitive workloads. Ballooning a database buffer cache causes severe degradation that the host considers gentle reclamation.
• Review memory limits during change management. Any memory limit on a production VM should be documented and justified. Most limits in production are forgotten leftovers from testing.

How Netdata helps

• Correlate balloon, compression, and swap in one view. Per-second resolution lets you watch MCTLSZ rise, ZIP/s follow, and SWCUR with SWR/s appear in the order the cascade actually runs.
• Surface the MCTLTGT vs MCTLSZ gap. When Tools is not running, MCTLTGT is non-zero while MCTLSZ stays at zero. Correlating the two surfaces the skip-to-swap failure mode before swap-in begins.
• Distinguish cascade latency from array latency. Per-datastore latency breakdown lets you confirm rising KAVG with flat DAVG before you page the wrong team.
• Per-host memory pressure, not cluster averages. Per-host consumed vs physical RAM means the one host at 95% does not hide behind a cluster average of 65%.
• Anomaly detection on reclamation metrics. The cascade has a characteristic shape: balloon, then compress, then swap. Anomaly detection can flag the leading edge of that shape before swap-in becomes a paging emergency.

Related guides

• vSphere CPU co-stop high (%CSTP): the SMP vCPU co-scheduling penalty
• vSphere CPU limit hit (%MLMTD): the forgotten MHz cap that silently throttles a VM
• vSphere CPU ready time high (%RDY): VMs starved while the guest looks idle
• vSphere host swapping (SWCUR/SWW/s): hypervisor swap and the memory death spiral
• How vSphere actually works in production: a mental model for operators
• vSphere memory ballooning (MCTLSZ): the host is reclaiming guest RAM
• vSphere monitoring checklist: the signals every host, VM, and vCenter needs
• vSphere monitoring maturity model: from survival to expert
• vSphere NUMA locality low: wide VMs paying the remote-memory tax
• vSphere vCPU oversizing: why adding vCPUs made the VM slower