vSphere host swapping (SWCUR/SWW/s): hypervisor swap and the memory death spiral

When SWR/s is sustained above zero on an ESXi host, the VMkernel is actively reading VM memory pages back from .vswp files on the datastore. That is not a warning state. It is an active performance emergency. Every swapped-in page costs roughly 100x DRAM latency, and the swap I/O itself competes with VM disk I/O on the same datastore, producing a double penalty that degrades every VM on the host simultaneously.

The critical distinction operators miss: SWCUR being non-zero only means pages were swapped out at some point. Those pages may never be touched again. The performance killer is SWR/s (swap-in rate). When a VM accesses a swapped page, the VMkernel must read it back from disk before the guest instruction can proceed. The guest stalls, the application stalls, and if enough VMs are stalling, the datastore saturates.

What this means

ESXi reclaims memory through a four-tier hierarchy, invoked in order of increasing desperation:

1. Transparent Page Sharing (TPS) deduplicates identical memory pages. Inter-VM TPS is disabled by default for security reasons, so only intra-VM page sharing occurs in practice.
2. Ballooning inflates the vmmemctl driver inside the guest, forcing the guest OS to page internally using its own swap or pagefile.
3. Compression packs pages into a per-VM compression cache. Pages that compress to a small enough size stay in DRAM at higher access latency rather than going to disk.
4. Host-level swapping writes VM memory pages to .vswp files on the datastore. This is the last resort.

When the host reaches tier 4, it has exhausted every gentler option. Each swapped page lives on a datastore (potentially a shared SAN), and every swap-in or swap-out I/O competes with normal VM disk I/O. The latency impact is catastrophic compared to DRAM, and the I/O contention creates a feedback loop.

The death spiral: swapping generates I/O, I/O latency causes applications to hold in-flight operations in memory longer (timeouts, retries, connection holds), the increased memory retention causes more pressure, which causes more swapping. This can happen in minutes during a workload spike. Memory degradation is cliff-edge, not gradual. The balloon-to-compress-to-swap transition can occur faster than a 5-minute polling interval can capture.

flowchart TD
    A[Host memory pressure] --> B[TPS: intra-VM dedup]
    B -->|insufficient| C[Ballooning: vmmemctl inflates]
    C -->|insufficient or Tools not running| D[Compression: ZIP/s]
    D -->|compression cache full| E[Swap OUT to .vswp: SWW/s]
    E -->|VM touches swapped page| F[Swap IN from .vswp: SWR/s]
    F --> G[Datastore I/O contention]
    G --> H[App latency and timeouts]
    H --> A

If you see swap activity with balloon at zero, VMware Tools is not running or the balloon driver is disabled. The host skipped directly to swap. This is the worst-case path because the host lost its gentlest reclamation tool and went straight to the most expensive one.

VMkernel swap is distinct from and additive to guest-internal swap. Ballooning forces the guest to page internally, and the host may also swap pages to .vswp. Both can happen simultaneously. A VM can suffer guest-internal paging (invisible to ESXi) and VMkernel swap (invisible to the guest) at the same time, compounding the latency penalty.

Common causes

Quick checks

These are read-only commands safe to run on any ESXi host or from a PowerCLI session.

# esxtop memory view: press 'm', look at SWCUR, SWR/s, SWW/s
# Press 'f' to add fields if any are missing
esxtop

# Host-level swap rates via PowerCLI (realtime, 20s interval)
Get-VMHost | Get-Stat -Stat mem.swapinRate.average -Realtime -MaxSamples 1
Get-VMHost | Get-Stat -Stat mem.swapoutRate.average -Realtime -MaxSamples 1

# Total swapped memory (cumulative snapshot, not a rate)
Get-VMHost | Get-Stat -Stat mem.swapped.average -Realtime -MaxSamples 1

# Balloon status per VM via PowerCLI
Get-VM | Select Name, @{N='BalloonedMB';E={$_.ExtensionData.Summary.QuickStats.BalloonedMemory}}

# VMware Tools status on all VMs
Get-VM | Select Name, @{N='ToolsStatus';E={$_.ExtensionData.Guest.ToolsRunningStatus}}

# Datastore latency where .vswp files reside
# In esxtop, press 'u' for disk device view, look at GAVG/KAVG/DAVG
esxtop

How to diagnose it

1. Confirm it is VMkernel swap, not guest-internal swap. Open esxtop, press m, and look at SWR/s. If it is non-zero, VMkernel swap-in is happening. Guest-internal swap does not appear here. Check inside the guest OS (pagefile usage on Windows, si/so columns in vmstat on Linux) to assess guest-internal paging separately.

2. Check balloon status alongside swap. If MCTLSZ is zero or near-zero while SWCUR is climbing, the balloon driver is not working. The most common reasons are VMware Tools not installed, Tools not running, or the balloon driver explicitly disabled. Verify Tools status first.

3. Check if a VM memory limit is forcing swap. A VM with sched.mem.max set below its configured memory can be forced to swap to .vswp even when the host has ample free memory. This is documented VMware behavior. Check the VM resource settings and any parent resource pool limits.

4. Compare SWCUR to SWTGT. SWTGT is the swap target computed by the memory scheduler. If SWTGT is greater than SWCUR, the VMkernel is actively trying to swap more pages out. If SWTGT is less than SWCUR, the host is working to unswap pages back into DRAM.

5. Check datastore latency on the datastore holding the .vswp files. In esxtop, press u and look at DAVG, KAVG, and GAVG for the device backing the datastore. Swap I/O adds load. If KAVG is elevated while DAVG is moderate, the VMkernel queue is absorbing swap I/O pressure.

6. Identify which VMs are being swapped most heavily. Sort by SWCUR in esxtop memory view. The VMs with the highest SWCUR combined with non-zero SWR/s are the ones experiencing active pain.

7. Check for the compression precursor. Look at ZIP/s and UNZIP/s in esxtop memory view. If compression is active alongside swap, the host is deep in the reclamation cascade and compression alone was insufficient. Compression sustained at non-zero is a TICKET-level signal on its own: the host is in the danger zone between ballooning and swapping.

8. Distinguish hypervisor swap from ballooning-induced guest swap. If balloon (MCTLSZ) is non-zero and the guest is paging internally, the guest swap is caused by the balloon driver reclaiming memory. This is “gentle” reclamation from the host’s perspective but may be severe from the guest’s. Both can coexist with VMkernel swap. Check guest-internal swap counters to assess total impact.

Metrics and signals to monitor

Fixes

Immediate: reduce pressure on the host

The fastest fix is to vMotion VMs off the pressured host to hosts with available memory. Identify the largest memory consumers (highest consumed or active memory) and migrate them first. This does not fix the underlying overcommitment, but it stops the death spiral.

If vMotion is not available or the cluster is universally pressured, the only immediate options are to suspend non-critical VMs or add physical memory to the host (requiring a reboot). Suspending VMs is disruptive. Document the action and prioritize recovery.

Fix the balloon driver

If MCTLSZ is zero across all VMs while swap is active:

• Verify VMware Tools (or open-vm-tools) is installed and running on every VM. Use Get-VM | Select Name, @{N='ToolsStatus';E={$_.ExtensionData.Guest.ToolsRunningStatus}}.
• Check if the balloon driver was explicitly disabled in the VM advanced settings.
• Update Tools if it is outdated. A crashed or hung Tools process can leave the balloon driver non-functional even though Tools appears installed.

Once Tools is running, the host can use ballooning as the first reclamation tier instead of jumping directly to compression and swap.

Remove memory limits

A VM with a memory limit (sched.mem.max set below configured memory) can be forced to swap even when the host has free memory. This looks like a host-level memory problem but is a per-VM configuration issue.

Check resource settings on affected VMs. Set the memory limit to Unlimited unless there is a specific, documented reason for the cap. The limit may have been inherited from a resource pool or set during testing and never removed.

Reduce VM memory allocations or add host RAM

If the host is genuinely overcommitted (total VM configured memory far exceeds physical RAM, and active memory demand is high), the long-term fix is to either add physical memory or reduce VM allocations. Memory reservations can protect critical VMs from ballooning and swap for the reserved amount, but they reduce the host’s flexibility to overcommit.

Physical RAM across the cluster should be 20-30% above total VM active memory, accounting for N+1 host failure capacity.

Consider host cache or NVMe tiering (version-dependent)

ESXi supports using local SSDs as a write-back cache for .vswp files, reducing swap latency compared to spinning disk or shared SAN. However, swap to host cache is deprecated in vSphere 9.0 and will be removed in a future release. In vSphere 9.0+, NVMe Memory Tiering replaces host cache as the recommended approach for reducing swap latency by using page aging to classify hot and cold pages rather than random page selection.

If you are on vSphere 7.x or 8.x and have local SSDs, enabling host cache can reduce the severity of swap events. It does not eliminate them.

Prevention

• Monitor reclamation indicators independently. Do not set a single host memory utilization threshold and call it done. Track balloon, compression, and swap as separate signals. A host at 85% consumed memory with zero balloon and zero swap is healthy. A host at 70% with active swap is in crisis.
• Ensure VMware Tools on every VM. Without Tools, the host loses ballooning and jumps directly to compression and swap. Audit Tools status regularly as part of VM provisioning.
• Avoid memory limits. Memory limits cause silent, hard-to-diagnose performance degradation. Use reservations if you need to guarantee memory to a VM, not limits to cap it.
• Track active:consumed memory ratio. If VM active memory consistently approaches consumed memory, the VM has little reclaimable memory and ballooning will force the guest to page actively, degrading performance even before swap begins.
• Plan for N+1 memory headroom. Losing one host should not push remaining hosts into the reclamation cascade.
• Watch for boot storms. Mass VM startup after host maintenance, power restoration, or VDI login storms can cause transient memory pressure. Brief swap during boot is expected. Sustained swap after boot completes is not.
• Review DRS aggressiveness and constraints. If DRS is in manual mode or constrained by affinity rules, it may not migrate VMs off pressured hosts. Verify that DRS can actually rebalance memory across the cluster when a host enters the reclamation cascade.

How Netdata helps

Netdata surfaces the VMkernel swap cascade at high resolution. The balloon-to-compress-to-swap transition can complete in minutes and disappear inside a 5-minute rolled-up average.

• Swap-in and swap-out rates let you see the exact moment SWR/s transitions from zero to non-zero, rather than discovering it after the spike has been smoothed away by rollup.
• Correlated balloon, compression, and swap metrics on a single timeline let you verify the reclamation cascade is following the expected order. If swap appears without preceding balloon activity, the anomaly is immediately visible and points to a Tools problem.
• Datastore latency alongside swap activity shows the I/O contention the swap is creating. Elevated KAVG correlating with SWW/s confirms the double penalty is active.
• Host memory consumed, active, and ballooned trends over hours and days reveal whether the host is trending toward a cliff-edge event or experiencing a transient spike that will self-resolve.
• Anomaly detection on memory reclamation metrics can flag unusual balloon or compression patterns before swap begins, giving operators lead time to rebalance the cluster before the death spiral starts.

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
• How vSphere actually works in production: a mental model for operators
• vSphere monitoring checklist: the signals every host, VM, and vCenter needs
• vSphere monitoring maturity model: from survival to expert