Wednesday, July 10, 2013

Memory Ballooning

The memory balloon driver (vmmemctl) collaborates with the server to reclaim pages that are considered least valuable by the Guest O.S. when the host memory constraint.  The Guest O.S. is not aware that it is running inside a VM, when the hypervisor runs multiple VMs and the total free host memory becomes low, none of the VMs will free Guest physical memory because Guest O.S. cannot detect the host’s memory shortage. Ballooning makes the Guest O.S. aware of the low memory status of the host. So that before Host will do the swapping of the memory pages, Guest O.S. can release the non- active pages from the host physical memory and host can have memory for demanding VMs.
A balloon driver is loaded into the Guest O.S. when VMware Tools are installed on VM as a pseudo-device driver and it communicates with the hypervisor through a private channel.
In Figure (a), four guest physical pages are mapped in the host physical memory. Two of the pages are used by the guest application and the other two pages (marked by stars) are in the guest operating system free list. Since the hypervisor cannot identify the two pages in the guest free list, it cannot reclaim the host physical pages that are backing them. Assuming the hypervisor needs to reclaim two pages from the VM, it will set the target balloon size to two pages. Then the balloon driver allocates two guest physical pages inside the virtual machine and pins them (move into the swap partition of Guest O.S. inside VMDK called Inflate), as shown in Figure (b) through Guest O.S. interface, which ensures that pinned pages cannot be paged out to disk (datastore on .vswp file) under any conditions. Once the memory is allocated, the balloon driver notifies the hypervisor about the page numbers of the pinned guest physical memory so that the hypervisor can reclaim the host physical pages that are backing them. In Figure (b), dashed arrows point at these pages. If any of these pages are re-accessed by the virtual machine for some reason, the hypervisor will treat it as a normal virtual machine memory allocation and allocate a new host physical page for the virtual machine. When the hypervisor deflates the balloon—by setting a smaller target balloon size—the balloon driver de-allocates the pinned guest physical memory, which releases it for the guest’s applications. The guest operating system must have sufficient virtual swap space configured for guest paging to be possible.
If necessary, you can limit the amount of memory vmmemctl reclaims by setting the sched.mem.maxmemctlparameter for a specific virtual machine. This option specifies the maximum amount of memory that can be reclaimed from a virtual machine in megabytes (MB).
Thanks to VMware, Information is from the white paper provided by VMware.
    

0 comments:

Post a Comment