memory, and unused or inactive application memory are all typical targets. If none of
those are available, the guest OS may choose to page out memory content to the guest
OS pagefile to generate free memory. The key is that the guest OS, rather than an
outside process that does not understand how memory is being used, gets to decide
intelligently which pages should be given in the most unobtrusive way, with the least
hit to performance. Once the memory is allocated to the balloon driver, these
addresses are communicated to the virtualization manager, which tells the hypervisor
it can now effectively unmap those address ranges from physical RAM because the
balloon driver will never actually touch them and no other part of the guest OS is
allowed to touch them. The memory has been reclaimed by Hyper-V, and it can be
used with other virtual machines.
If the virtual machine needs additional memory in the future, the VM management
can “deflate” the balloon, either fully or by a certain amount. Physical RAM is
provided by Hyper-V at its previous locations, and then the balloon driver frees the
previously allocated RAM back to the guest OS. This process is shown in Figure 2. 16.
Figure 2. 16 The inflation of the balloon driver to allow Hyper-V to reclaim memory
from a virtual machine
It is still critical to understand and plan placement of virtual machines based on
expected memory usage and to set realistic maximum values. Poor planning will result
in the host running out of memory and virtual machines not getting enough RAM.
While Dynamic Memory is great for client operating systems in Virtual Desktop
Infrastructure implementations, it also works well for many server workloads. I’ve
seen many organizations use Dynamic Memory on all types of server workloads like
file servers, domain controllers, System Center servers, and more, and get huge