vSphere memory ballooning (MCTLSZ): the host is reclaiming guest RAM

You open esxtop, switch to the memory view, and a VM’s MCTLSZ column is no longer zero. A few hundred megabytes or several gigabytes, the VMkernel has inflated the vmmemctl balloon driver inside that guest and is forcing the guest OS to hand back memory it thought it owned. From the host’s perspective this is gentle reclamation. From the guest’s and the application’s perspective, it is often the start of a silent performance decline.

Ballooning is the second tier in ESXi’s memory reclamation hierarchy, after transparent page sharing (TPS) and before compression and host-level swap. Because inter-VM TPS has been disabled by default since ESXi 6.0 for security reasons, ballooning is the first active reclamation mechanism on most modern hosts. When you see it sustained and non-zero in production, the host is overcommitted or a VM-level limit is forcing reclamation. The question is not whether there is a problem, but how far down the cascade you are about to slide.

The damage happens inside the guest. To satisfy the balloon’s allocations, the guest OS pages to its own swap or pagefile. ESXi cannot see this internal paging. Your host-level dashboards look calm while a database whose buffer cache was just ballooned away starts hitting disk on every query. The reclamation the host considers polite is, for a latency-sensitive workload, a direct hit to working set.

What this means

MCTLSZ is the current size of the balloon inside a given VM, reported in MB in esxtop’s memory view. The corresponding vCenter counter is mem.vmmemctl.average, reported in KB. Its companion is MCTLTGT, the target size the VMkernel wants the balloon to reach. When MCTLTGT is greater than MCTLSZ, the host is still inflating. When MCTLTGT drops toward zero, the host is satisfied and the balloon deflates, letting the guest reclaim those pages.

The balloon works by collaboration. The vmmemctl driver runs inside the guest as part of VMware Tools (or open-vm-tools). When the host needs memory, it tells the driver to allocate pages. The driver grabs from the guest’s free list first, then from least-recently-used pages. To free those pages, the guest OS must page them out to its own backing store. That paging is real I/O against the guest’s virtual disk, and it is entirely invisible to ESXi.

Two operational facts shape everything that follows. First, ballooning requires VMware Tools to be installed and the vmmemctl driver to be running. If Tools is absent or the driver is disabled, the host cannot balloon that VM and skips directly to compression and host swap, a far worse outcome. Second, a memory reservation exempts the reserved amount from ballooning, compression, and host swap. A fully reserved VM is immune to reclamation, at the cost of removing that RAM from the host’s shared pool.

flowchart TD
  A["Host memory pressure builds"] --> B["TPS: dedup identical pages"]
  B -- "disabled by default since ESXi 6.0" --> C["Ballooning: vmmemctl inflates"]
  C --> D["Guest pages to its own swap/pagefile"]
  D --> E{"Pressure relieved?"}
  E -- "no" --> F["Compression: pages into cache"]
  F -- "cache fills" --> G["Host swap: pages to .vswp"]
  G --> H["Datastore latency rises"]
  E -- "yes" --> I["Balloon deflates"]

Ballooning is the first tier where the guest does work it would not otherwise do. Compression adds CPU cost and higher DRAM latency on decompression. Host swap writes VM memory pages to .vswp files on the datastore, where the I/O competes with your VMs’ own disk traffic. Each step down is progressively worse, and the transition can happen in minutes during a workload spike.

Common causes

A memory limit is the most easily missed cause. Setting a limit below configured memory tells the VMkernel to reclaim the difference even when the host is idle. The VM balloons itself into its own limit. This is functionally indistinguishable from host pressure from inside the guest, and it is a common inheritance from old templates.

Quick checks

These are read-only and safe to run on a production host.

# Memory view in esxtop; look at MCTLSZ and MCTLTGT per VM
esxtop
# press 'm' for memory view, then 'f' to add fields if columns are missing
# sort by MCTLSZ to find the most-ballooned VMs

# Per-VM ballooned and swapped memory via PowerCLI (QuickStats are in MB)
Get-VM | Select Name,
  @{N='BalloonedMB';E={$_.ExtensionData.Summary.QuickStats.BalloonedMemory}},
  @{N='SwapMB';E={$_.ExtensionData.Summary.QuickStats.SwappedMemory}}

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

# Check whether a memory limit is set on a suspicious VM (-1 means unlimited)
Get-VM "problem-vm" | Select Name,
  @{N='MemLimitMB';E={$_.ExtensionData.ResourceConfig.MemoryAllocation.Limit}}

# vCenter counter for the balloon size (KB), realtime
Get-Stat -Entity (Get-VM "problem-vm") -Stat mem.vmmemctl.average -Realtime -MaxSamples 6

The pairing that matters is MCTLSZ against MCTLTGT. If the target is well above the current size, the host still wants more from that VM and the balloon is growing. If you see host swap activity (SWCUR greater than zero, or mem.swapinRate.average greater than zero) with MCTLSZ at zero on a particular VM, that VM almost certainly does not have a working balloon driver.

How to diagnose it

1. Confirm the scope. Is ballooning on one VM, a cluster of VMs, or every VM on the host? Cluster-wide ballooning points at host overcommitment or a DRS problem. One VM points at a limit, a leak, or a reservation mismatch.
2. Compare host consumed memory against physical RAM. As a warning threshold, sustained consumption above roughly 85% warrants investigation. The vSphere 8.0 monitoring documentation defines consistently high memory usage at 94% or greater — equivalently, free memory of 6% or less — as a clear indicator that the host lacks memory and cannot handle demand.
3. Compare VM active memory against configured memory. A VM whose active memory is close to configured while it is being ballooned is genuinely being starved of working set. A VM with low active memory and high ballooning is giving up idle pages, which is less harmful.
4. Check for forgotten limits on the affected VMs and any parent resource pools. A limit anywhere in the hierarchy forces reclamation.
5. Verify VMware Tools is running and the vmmemctl driver is loaded on the ballooning VMs. If Tools is absent, the host silently skips that VM and over-balloons the others, or skips straight to swap.
6. Look one tier down. Is compression active? Is host swap active (SWCUR or swap-in rate greater than zero)? If either is true, you are already past the gentle stage and the situation is urgent.
7. Check guest-internal paging from inside the VM. This is the only way to see the actual cost of ballooning, because ESXi is blind to it.

Metrics and signals to monitor

The single most common monitoring mistake is treating host memory as a percentage. A host at 85% consumed might be completely fine, or it might be actively swapping. The percentage tells you nothing about which tier of reclamation is active. You must monitor balloon, compression, and swap as independent signals.

Fixes

Reduce pressure on the host

The only durable fix for host-wide ballooning is more physical memory or fewer VMs. If one VM is consuming a disproportionate share, vMotion other VMs off the host to give it headroom. If the overcommit is systemic, either add RAM or reduce the configured memory of VMs that are carrying idle allocations. Right-sizing is unglamorous, but it is the only thing that solves the root cause.

Remove forgotten memory limits

If a VM is ballooning while the host has free memory, look for a limit on the VM or on a parent resource pool. Removing the limit (setting it to unlimited) immediately lets the VM use its configured memory. Confirm the VM is not limited on purpose for a noisy-neighbor reason before removing it.

Protect critical VMs with reservations

A memory reservation exempts that amount from ballooning, compression, and swap. For latency-sensitive workloads like databases or in-memory caches, a reservation equal to the working set is the cleanest way to guarantee the balloon never touches them. The trade-off is that reserved RAM leaves the host’s shared pool, which increases overcommitment pressure on everything else. Use reservations deliberately, not broadly.

Confirm VMware Tools on every VM

If Tools is missing or the balloon driver is disabled on some VMs, the host cannot reclaim from them politely and will either over-balloon the VMs that do have Tools or skip to compression and swap. Fixing Tools status on one VM can materially reduce pressure on the rest. This is one of the highest-leverage, lowest-risk fixes available.

Adjust the per-VM balloon cap only as triage

The advanced per-VM setting sched.mem.maxmemctl caps how much the balloon can reclaim from a specific VM, in MB. Lowering it protects that VM but shifts pressure elsewhere, often to swap. Raising it lets the host reclaim more from a VM that can tolerate it. Neither solves an overcommitted host; both just move the pain. Treat changes here as triage, not as a fix.

Prevention

• Right-size at provisioning time. VMs with far more configured memory than they use inflate host overcommitment for no benefit. Track active vs configured memory and trim allocations that never get touched.
• Track active memory, not just consumed. Consumed includes idle pages. A VM can show high consumed and low active memory, meaning it is a safe ballooning target. The reverse means it is not.
• Standardize on VMware Tools. Make Tools status a gating check. A host full of VMs without working balloon drivers cannot reclaim gracefully and will go straight to swap under pressure.
• Reserve only what truly needs it. Reservations are the right tool for databases and similar working-set-sensitive workloads. Blanket reservations remove the host’s flexibility and push pressure onto everything else.
• Watch the whole cascade, not just ballooning. Alert on balloon, compression, and host swap as a group. Catching ballooning early lets you act before compression and swap engage.
• Plan capacity against active memory plus headroom. Physical RAM should sit comfortably above total VM active memory, with room for N+1 host failure. Growth is often stepwise when new VMs are added, so revisit this whenever provisioning.

How Netdata helps

• Correlate per-VM mem.vmmemctl.average with host consumed memory and swap-in rate to determine whether the problem is one VM or the entire host.
• Per-second resolution catches the MCTLSZ ramp while MCTLTGT is still climbing, before compression or swap engages.
• Pairing balloon with compression and swap-in rate shows where you are in the cascade in real time.
• ML anomaly detection on per-VM balloon size flags unusual patterns, such as one VM ballooning while the host otherwise looks healthy.
• Guest-level memory metrics collected inside the VM expose the internal paging ESXi cannot see.
• Long-duration retention of active vs consumed memory per VM supports right-sizing decisions over weeks.

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