How virtualization dynamic memory works
- select the contributor at the end of the page -
On the last Tuesday of each month, join IT expert and Pluralsight author Don Jones for his IT ops news and talk show. He’ll cover the hottest tidbits of industry news and their impact on you, and feature guests that will help you improve your skills and keep up with our fast-changing jobs. These “rants” are excerpts from Don’s previous webinar. Enjoy!
Dynamic memory is a highly marketed feature of both vSphere and Hyper-V, allowing you to assign more memory to the virtual machines on a host than that host actually contains. It’s also referred to as memory overcommit, which is a very accurate description for what you’re really doing. But how does this thing work its magic under the hood?
Before dynamic memory was a thing, every byte of virtual memory assigned to virtual machines had to be backed up by the same amount of physical memory. This was a one-to-one mapping. It’s because the physical processor in the host has to manipulate data someplace, and memory is that place. The problem is that the host can’t see “inside” the VM to see what memory is actually being used, and so it had to assume ALL the memory was being used.
Dynamic memory relies on the fact that, in operating systems like Windows and Linux, memory is actually divided into two spaces. User mode is where applications run, and kernel mode is where critical system drivers and services run. The trick with kernel mode is that the OS makes an important assumption: Anything running in kernel mode is absolutely required in order for the machine to run. So when something in kernel mode asks for memory, it simply HAS to have it, even if that means making less memory available to user mode.
So dynamic memory takes the form of a kernel mode device driver, like a video driver or network driver. The host hypervisor is able to communicate with this driver, and tell the driver when it wants the virtual machine to use less physical memory.
When that happens, the so-called balloon driver, running in kernel mode, asks for memory from the OS. The OS is obligated to provide that memory, and reduces the available amount of user mode memory to do.
Once the balloon driver has the memory it wants, it writes zeros into that memory space. Now, the balloon driver knows what memory it has assigned, and it knows that the memory isn’t actually in use. That means it’s safe for the hypervisor to no longer map that virtual memory to physical memory – freeing up the physical memory to be mapped elsewhere. It’s a pretty neat trick – and now you know how it’s done.