VM Memory Ballooning: Fix Slow VMs Now

Server & Cloud Intermediate 👁 18 views 📅 Jun 28, 2026

If your VM runs slow and the host has free RAM, ballooning is likely the culprit. Turn it off per VM for an instant fix. Here's how.

When the guest OS shows 90% memory used, but the host has 50% free, that's ballooning.

You're not the first person to bang your head against this. It's frustrating – your VM is crawling, apps are timing out, and yet when you look at the ESXi host, there's plenty of RAM sitting there doing nothing. The real culprit is VMware's memory balloon driver (vmmemctl). It's a kernel module that forces the guest to free up memory by inflating a fake process. The host needs RAM, but the balloon driver doesn't always let go when the pressure's gone. Here's how to kill it.

Step-by-Step: Turn Off Ballooning Per VM

  1. Shut down the VM. Not reboot. Full power off. You can't change memory settings while it's on.
  2. In vCenter, find the VM. Right-click it > Edit Settings.
  3. Expand Memory section. Look for “Memory Hot Plug” – leave that off for now.
  4. Click the arrow next to “Advanced Parameters”. If it's grayed out, you need to enable “Configuration Parameters” first (click the “VM Options” tab > General > Configuration Parameters > Edit).
  5. Add a new parameter: Click “Add Parameter”. In the Name field type sched.mem.maxmemctl. In the Value field type 0. Click OK.
  6. Apply and close. Then power on the VM.

What you should see: After the VM boots, open Task Manager (Windows) or free -h (Linux). The memory usage will drop by a lot – maybe 30-40%. The balloon driver is no longer holding pages. Also check the host's memory usage in vCenter – it should show less overhead for that VM.

Why This Works

The sched.mem.maxmemctl parameter limits how much memory the guest can “give back” to the host via the balloon driver. Setting it to 0 means the balloon driver can't take any memory from the guest. The host will then use other methods (like swapping via the VMkernel swap file) if it gets low on RAM, but that's actually better – the guest OS keeps its own memory management intact. Ballooning is VMware's brute-force way to reclaim memory, but it often causes thrashing because the guest OS fights back.

Less Common Variations of This Issue

Sometimes ballooning is triggered by a misconfigured resource pool or a high share value on another VM. Here's what to check:

  • Resource pool limits: If the VM is in a resource pool with a “Reservation” set, and that reservation is below the VM's configured memory, ballooning kicks in to keep the pool's math happy. Go to the Resource Pool > Edit Settings > Memory > set Reservation to 0 or match it to the VM's memory.
  • Memory overhead: VMware reserves some memory per VM for its own use (about 5-10%). If you have 20 VMs on a host with 256GB RAM, the overhead alone can push the host into ballooning territory. Consider adding more RAM to the host, or reducing the number of VMs.
  • Ballooning on Linux: On some Linux kernels (especially RHEL 7 and 8 with kernel 3.10), the balloon driver can get stuck in a loop where it inflates but never deflates. Check dmesg | grep balloon – if you see repeated “balloon: inflate 1024 pages” messages, you're in that loop. The fix is the same: set sched.mem.maxmemctl=0 via vCenter.
  • VMware Tools version: Old VMware Tools (before 10.3.0) had a bug where the balloon driver wouldn't release pages after memory pressure dropped. Upgrade VMware Tools on the guest to the latest version from your vCenter's “Hosts and Clusters” view.

How to Keep Ballooning From Coming Back

Once you've turned it off, you need to make sure the host doesn't keep trying to use it. Here's the plan:

  • Set a reservation on each VM. Go to VM Settings > Memory > Reservation. Set it to the same number as the VM's configured memory (e.g., 8GB for an 8GB VM). This tells the host: “don't touch my RAM, it's mine.”
  • Monitor host memory pressure. Use esxtop on the ESXi host. Look at the “M” column (memory) and check for “%ACTV” – if it drops below 80%, you're running out of RAM. Add more memory or reduce VM count.
  • Disable ballooning at the cluster level (optional). If you have many VMs and want to save time, go to vCenter > Hosts and Clusters > right-click your cluster > Edit Settings > VMware EVC > Advanced > check “Disable memory ballooning”. But I don't recommend this – it's a blunt tool. Better to control it per VM.
  • For critical VMs (SQL servers, Exchange): Set sched.mem.pin to TRUE in the VM's advanced parameters. This pins memory so the host can't swap it out at all. Warning: this uses more host resources because the host must keep that RAM available.
One more thing: don't confuse ballooning with memory overcommitment. Overcommitment is fine – it's when you allocate more RAM to VMs than the host has, expecting them not to use it all. Ballooning is the mechanism that enforces that. If your VMs actually need the RAM, overcommitment breaks. Check your historical usage.

That's it. You should see your VM's performance jump back to normal within minutes. If it doesn't, you might have a deeper issue – like a misconfigured NUMA topology or a bug in the ESXi version (patch to 6.7U3 or newer). But 9 times out of 10, the balloon driver is the problem. Kill it, and move on.

Was this solution helpful?