Hypervisor Memory Ballooning Failure – Real Fixes

Cause 1: Host ran out of swap space for balloon driver

The balloon driver needs swap space on the ESXi host to work. If you're out of swap, the driver can't inflate and you get the failure. I've seen this happen on a client's Dell R730 running ESXi 7.0 U3 — they had 256 GB RAM and only 4 GB swap. The VM memory ballooning failure showed up every time they overcommitted memory.

How to fix it

Check your host swap usage:

esxcli sched swap -l

If it's 100% used, increase swap space. For ESXi 6.5 and later, you can set a larger swap file. Use:

esxcli system settings advanced set -o /Config/OverheadSwapMinMB -v 2048

That sets min swap to 2 GB per VM. But the real fix is to add more swap to the host itself. Edit the advanced setting:

esxcli system settings advanced set -o /Mem/CtlSwapMaxPercent -v 100

This lets ballooning use up to 100% of host swap. Restart the VM after changing it. If you can't edit advanced settings, use the vSphere client: go to the host, Configure, System, Advanced System Settings, search for Mem.CtlSwapMaxPercent and set it to 100.

Don't mess with this if you don't know what you're doing. A wrong value can crash the host. I've had a client do that once — had to restore from backup.

Cause 2: Balloon driver crashed or unloaded

The balloon driver runs inside the VM. It's a kernel module. Sometimes it crashes due to a memory leak or a bug in VMware Tools. I fixed this for a small law firm — they had 10 VMs on one host, and one VM kept losing the balloon driver. The failure showed up every 3 days.

How to fix it

First, check if the balloon driver is running inside the VM:

# On Linux VM
lsmod | grep vmxnet3
# Look for vmxnet3 or vmmemctl
lsmod | grep vmmemctl

If it's missing, reinstall VMware Tools. On Linux, run:

sudo vmware-config-tools.pl -d

On Windows, go to Programs and Features, right-click VMware Tools, choose Change, then Repair. Or check the VMware Tools version — old versions have bugs. Upgrade to the latest:

# For ESXi 7.0+
# Download the latest Tools ISO from VMware, mount it to the VM, then run the installer

If reinstalling doesn't fix it, check the VM's log at /var/log/vmware/vmware.log for "balloon" or "vmmemctl" errors. I found one where a custom kernel module was blocking vmmemctl from loading. Removing that module fixed it.

Cause 3: Host memory overcommit too high — balloon driver hits limit

Ballooning has a limit — the vmmemctl driver can only reclaim up to 65% of VM memory by default. If your host is overcommitted beyond that, ballooning fails and you get the error. This happened to a client running 20 VMs on a single host with 128 GB RAM — they were overcommitted at 150%.

How to fix it

Reduce overcommit. The quick fix is to set a higher balloon limit. On the ESXi host, run:

esxcli system settings advanced set -o /Mem/CtlMaxPercent -v 80

This sets the max balloon reclaim to 80% of VM memory. Don't go above 90% — the VM will become unusable. I tried 95% once on a test VM, and it crawled.

Better fix: use memory reservation on critical VMs. For each VM, set a reservation equal to its expected workload. In the VM settings, go to Memory, and set Reservation to, say, 4 GB. This tells ESXi to keep that much RAM free, so the balloon driver doesn't have to work as hard.

Reservation can cause fragmentation. Don't use it on all VMs — only the ones that need it. Also, check your host's memory usage with esxtop. Press m to see memory details. If ballooning is at 0% and you still see the error, it's likely cause 1 or 2.

Quick-reference summary table

If none of these works, check the VM's vmx file for a line like "sched.mem.pin" or "mem.hotadd" — those can interfere with ballooning. Remove them if present. Also, make sure the VM has VMware Tools installed and running. Without it, ballooning won't work at all.

I've been fixing this for years. Most of the time it's one of these three causes. Try them in order — you'll save hours.