In this lesson, you will learn how hypervisors use memory ballooning to dynamically redistribute physical RAM among multiple guest virtual machines without relying on traditional swap space.
The Problem: Static Allocation vs. Dynamic Demand
When you assign a fixed amount of RAM to a virtual machine (VM), that memory is effectively "reserved" from the host's perspective, even if the guest kernel is mostly idling. If a guest doesn't need all its RAM, that physical memory sits wasted while another VM might be struggling under heavy load. Memory ballooning solves this by introducing a cooperative driver inside the guest kernel that can "inflate" or "deflate" on demand.
How the Balloon Driver Works
The balloon driver operates as a special kernel module within the guest OS. It communicates with the host hypervisor (such as KVM or VMware) to exchange memory pressure information:
- Inflation: When the host needs more physical RAM for other processes or VMs, it signals the guest’s balloon driver. The driver then invokes the guest kernel’s page allocator to reserve a chunk of physical memory, effectively "inflating" the balloon.
- Memory Pressure: Because the guest kernel has now allocated that memory to the balloon driver, the guest’s own memory pressure increases. The guest kernel is forced to invoke its internal reclamation strategies—such as dropping caches or invoking its OOM killer—to free up pages for the balloon.
- Deflation: When the guest needs more memory, or the host has surplus capacity, the hypervisor tells the balloon driver to release those pages back to the guest kernel, "deflating" the balloon and returning the memory to the guest’s free pool.
Why not use Swap?
Unlike traditional swapping (which moves data to slow disk storage), memory ballooning is highly efficient because it keeps memory in high-speed physical RAM. It relies on the guest kernel's own internal visibility to decide which pages are least important to reclaim. From the guest kernel's perspective, it looks exactly like the system is under memory pressure, triggering standard kernel mechanisms like page cache eviction or moving anonymous pages to the guest's own swap partition if necessary.
/* Conceptually, the balloon driver requests pages from the kernel: */
void* page = alloc_page(GFP_KERNEL);
/* These pages are then held and hidden from user-space,
effectively reducing the guest's available free memory. */
Key Takeaway: Memory ballooning allows a host to reclaim physical RAM from a guest kernel by forcing the guest to internalize the memory pressure and surrender pages back to the host's pool.