Information Technology Reference
In-Depth Information
that contain identical memory. If it i nds a hash match, it compares the matching memory pages
to exclude a false positive. Once the pages are coni rmed to be identical, the hypervisor will
transparently remap the memory pages of the VMs so they are sharing the same physical mem-
ory page. This reduces overall host memory consumption. Advanced parameters are available to
i ne-tune the behavior of the page-sharing mechanisms.
Normally, ESXi works on 4 KB memory pages and will use transparent page sharing on all
memory pages. However, when the hypervisor is taking advantage of hardware ofl oads avail-
able in the CPUs—such as Intel Extended Page Tables (EPT) Hardware Assist or AMD Rapid
Virtualization Indexing (RVI) Hardware Assist—then the hypervisor uses 2 MB memory pages,
also known as large pages. In these cases, ESXi will not share these large pages, but it will com-
pute hashes for the 4 KB pages inside the large pages. In the event that the hypervisor needs
to invoke swapping, the large pages will be broken into small pages, and having the hashes
already computed allows the hypervisor to invoke page sharing before they are swapped out.
Ballooning
We mentioned previously that ESXi's memory-management technologies are guest OS agnostic,
meaning that the guest OS selection doesn't matter. This is true; any supported guest OS can
take advantage of all of ESXi's memory-management functionality. However, these technologies
are not necessarily guest OS independent, meaning that they operate without interaction from
the guest OS. While transparent page sharing operates independently of the guest OS, balloon-
ing does not.
Ballooning
involves the use of a driver—referred to as the balloon driver—installed into
the guest OS. This driver is part of VMware Tools and gets installed when VMware Tools is
installed. Once installed into the guest OS, the balloon driver can respond to commands from
the hypervisor to reclaim memory from that particular guest OS. The balloon driver does this
by requesting memory from the guest OS—a process calling
inl ating
—and then passing that
memory back to the hypervisor for use by other VMs.
Because the guest OS can give up pages it is no longer using when the balloon driver requests
memory, it's possible for the hypervisor to reclaim memory without any performance impact on
the applications running inside that guest OS. If the guest OS is already under memory pres-
sure—meaning the amount of memory coni gured for that VM is insufi cient for the guest OS
and its applications—it's very likely that inl ating the balloon driver will invoke guest OS pag-
ing (or swapping), which will impair performance.
How Does the Balloon Driver Work?
h e balloon driver is part of VMware Tools, which were described in detail in Chapter 9. As such,
it is specifi c to the guest OS, meaning that Linux VMs would have a Linux-based balloon driver,
Windows VMs would have a Windows-based balloon driver, and so forth.
Regardless of the guest OS, the balloon driver works in the same fashion. When the ESXi host is
running low on physical memory, the hypervisor will signal the balloon driver to grow. To do this,
the balloon driver will request memory from the guest OS. h is causes the balloon driver's memory
footprint to grow, or to
infl ate
. h e memor y that is granted to the balloon driver is then passed back
to the hypervisor. h e hypervisor can use these memory pages to supply memory for other VMs,
reducing the need to swap and minimizing the performance impact of the memory constraints.
When the memory pressure on the host passes, the balloon driver will
defl ate
, or return memory
to the guest OS.
