the memory that they can use for cache purposes, to help improve performance by
preloading programs into memory. If memory is available, it makes sense to use it to
try to improve performance. Leaving memory free does not benefit anyone, which is
why it’s rare to see a high Free Memory value on Windows Server 2008 and above. It
is because nearly all memory is always used that memory overcommit technologies
such as Allocate on First Write (which assigns memory as the virtual machine writes
data) don’t work well with modern operating systems and why Hyper-V does not use
that memory optimization technique. The memory used for caching can be used by
applications whenever needed, so the memory used for cache is largely still available,
and therefore looking at free memory is fairly meaningless. We need to consider the
available memory (which includes most of the memory being used for cache), which
can be seen in Figure 2.15 as well.
Dynamic Memory uses the commit value for memory to identify the amount of
memory that is used, and therefore its memory demand, and it is key to the
intelligence it brings to memory allocation. Hyper-V Integration Services has a
Dynamic Memory virtual service client (VSC) in the guest OS that communicates with
its corresponding virtual service provider (VSP) in the parent partition to report its use
of memory and specifically its amount of available memory. Based on the amount of
available memory in the guest, the desired memory buffer configured for the virtual
machine and the amount of physical RAM available in the host additional memory
may be allocated to the guest. This type of intelligent memory allocation is possible
only because of the guest OS insight provided by the Dynamic Memory VSC. It would
not be possible if the hypervisor was looking only at which memory is being used by a
virtual machine externally, because it would not be possible to tell whether the
memory was being used by an application or just for disposable purposes like pre-
caching.
While adding memory to a virtual machine is fairly simple—more memory is simply
presented to the guest OS for it to consume—the process of removing memory that is
no longer needed is more complex. You can’t just take memory away from a guest
operating system’s memory manager and expect it to continue to function. The guest
was probably using the memory (remember that little memory is actually free in a
modern operating system) and, even it was truly free, the guest expects it to be usable
in the future. Moreover, even if memory could be taken from a virtual machine, it
would be difficult to know what memory is safest to take back! Hyper-V uses a process
called ballooning to get around these problems and remove memory.
Ballooning is a clever way to get the guest operating system to decide which memory it
no longer needs and discontinue use of that memory. A “balloon” of memory is
allocated by a kernel mode device driver under Hyper-V’s control. When Hyper-V
wants memory back from a Dynamic Memory VM, it requests the balloon driver to
allocate memory inside that VM. The driver, running inside the guest OS, allocates the
memory and grows the “balloon” to a certain size. When a modern OS receives a
memory allocation request, it uses insight into existing memory content and workload
activity to decide where that memory can best come from. Free memory, cache