Ballooning is an effective VM memory management technique, but it does have its downfalls, such as potential memory overcommitment and halting application performance.
Most hypervisors provide multiple memory management techniques to help IT administrators optimize virtual servers and ensure that their VMs deliver sufficient performance. One common technique is memory ballooning, which enables the host computer to use unassigned VM memory.
When configured, memory ballooning automatically kicks in and borrows unused memory from other VMs if the hypervisor needs additional memory to run all the VMs within a host. Memory ballooning makes it possible to assign more memory beyond the available physical memory -- without overprovisioning -- to VMs collectively.
In a typical configuration, a host has limited insight into a VM's memory. The only information a host can access is the amount of memory allocated to the hypervisor and that the hypervisor cannot use the memory for other purposes. A host cannot determine which memory resources VMs underutilize and are available for other operations.
Similarly, the guest OS has no knowledge of a host's total available physical memory or how much of that memory a host allocates to various VMs. But the guest OS does know how much memory is available and which pages it can safely remove from memory and repurpose.
Digging into memory ballooning
Memory ballooning enables a hypervisor to share unused memory in some VMs with other VMs on the same host. Ballooning transfers the decision to allocate available memory resources from the host to the VM where it can make a more accurate assessment of memory resources.
To facilitate this process, admins install a balloon driver on each participating VM, which interfaces with a hypervisor to carry out memory reallocation.
When correctly implemented, memory ballooning is an effective strategy for memory management without affecting application performance of VM memory sharing.
Suppose an admin manages a host with 120 GB of available physical memory. The host supports 10 virtual servers with 16 GB of memory assigned to each VM, for a total of 160 GB. In most workloads, each VM can operate on 8 GB of memory or less, leaving plenty of unused memory.
But if one or more VMs requires additional memory or the admin must deploy additional VMs, memory ballooning lets them share unused memory with the VMs that need it without disrupting current operations.
When a hypervisor requires memory resources, it communicates with the balloon driver in each VM and requests a specific amount of memory. The driver then launches a pseudo-process that reserves the specified memory amount if it is available. The pseudo-process inflates -- similar to a balloon -- to prevent other VMs from using the reserved memory pages.
The balloon driver then notifies the hypervisor of the allocated memory resources and details which memory pages the hypervisor can reclaim. Because other VMs are not using this memory, the hypervisor can temporarily reallocate it to other VMs without affecting any workloads on the original VMs.
The exact implementation method for memory ballooning varies from hypervisor to hypervisor, but the basic principles are similar. For example, the VMware ESXi balloon driver deploys a pseudo-device driver to each VM.
The balloon driver includes no external interfaces to the guest OS and uses a private channel to communicate with the hypervisor and ensures that the reserved memory is available.
Microsoft Hyper-V and KVM include similar mechanisms: The hypervisor works in conjunction with the balloon driver to reallocate memory resources from one VM to another.
The flipside of memory ballooning
When correctly implemented, memory ballooning is an effective strategy for memory management without affecting application performance of VM memory sharing. Ballooning delivers memory to the VMs that need it and when they need it, without having to overprovision the physical memory. This results in better resource utilization, lower costs and simplified administration operations.
However, memory ballooning also presents several challenges. For example, the balloon driver must properly reallocate enough memory without affecting operations to get the inflating balance just right.
If the pseudo-process inflates too much, the guest OS could run low on memory and swap memory pages to disks and affect application performance. The guest OS might not have enough virtual drive space to support page swapping, which brings performance to a standstill.
Memory ballooning might not occur quickly enough to meet VM demands, especially if multiple VMs simultaneously request additional memory. Coinciding requests strain processor, storage and memory resources and affect the entire hypervisor. Memory ballooning can adversely affect applications that have built-in memory management, such as Java-based software.
Memory ballooning vs. dynamic allocation
Admins must not confuse memory ballooning with other types of memory management techniques; ballooning is sometimes considered a type of dynamic memory allocation where memory is automatically allocated when needed. This is true in some cases, where the ballooning mechanism does enable a dynamic allocation process.
But dynamic allocation can also refer to something much different, especially when implemented in Hyper-V systems. This form of dynamic allocation does not involve VM-based drivers or memory borrowing to support VMs, and admins can't assign a specific amount of memory to a VM.
Rather, dynamic memory allocation in a Hyper-V context relies on an available range. When first launched, a VM starts with a smaller amount of memory and acquires additional memory if and when it's needed from a resource pool that is available to all VMs.
This type of dynamic memory allocation can cause memory overcommitment if the hypervisor overprovisions VM memory; the total amount of memory assigned to VMs exceeds the available physical memory.
If admins use dynamic allocation and they overprovision memory in VMs, they are working under the assumption that not all VMs require all the memory available to them.
Memory ballooning is also a type of memory overcommitment; the two go together. There is no reason for admins to use ballooning if they are not overprovisioning their memory resources. The biggest advantage of overcommitment is better resource utilization. The biggest disadvantage is the risk that the necessary memory will not be available if all VMs simultaneous require memory.
Making the most of memory ballooning
Memory ballooning is an effective strategy for managing memory in VMs. Other strategies have also proven useful, such as memory compression and transparent page sharing, but admins have the advantage of using memory ballooning only when memory resources are running low, so it doesn't incur the same overhead as other techniques.
However, memory ballooning has its downsides, such as the possibility of memory overcommitment. Admins shouldn't blindly implement memory ballooning, but it's definitely a main option for them to consider.
