Microsoft Windows Server 2008 R2 Service Pack 1 will introduce two major new features: RemoteFX and Dynamic Memory. I've written about RemoteFX before (as has Brian), so today's focus is Dynamic Memory (from the VDI perspective). We'll also look at the inevitable question of how it compares to the memory management technologies in VMware ESX.
What is Dynamic Memory?
Dynamic Memory is a new feature of Microsoft Windows Server 2008 R2 Service Pack 1, or more specifically Hyper-V in Microsoft Windows Server 2008 R2 SP1. It lets you to take all of the memory in that Hyper-V host and dynamically distribute it across all of the VMs. (Hence the name "Dynamic Memory" -- possibly the first time a Microsoft feature name actually makes sense!) Dynamic Memory changes the way Hyper-V manages memory and makes it closer to the way CPU resources are managed, namely, shared across all VMs on the host. While I wish Dynamic Memory was as exactly as "dynamic" as CPU, we aren't quite there yet. In reality, the Dynamic Memory feature basically automates hot adding and removal of memory to a guest VM. (Super virtualization geeks might remember that the hot adding of memory in Hyper-V was actually planned for the first release back in 2007 but never made it.)
How does Hyper-V Dynamic Memory work?
The best non-technical way describe how Dynamic Memory works is to say that Hyper-V will give the guest VMs the right amount of RAM based on their actual usage. Of course there's a little bit more to it than that. Dynamic Memory works with the ‘driver enlightened’ architecture of Hyper-V. On the Hyper-v host, the Virtual Service Provider (VSP) manages the allocation of physical memory resources between the various virtual machines running on the host. Inside the enlightened guest, the Virtual Service Consumer (VSC) collects the information to determine virtual machine’s memory needs and executes necessary operations to add or remove memory.
Sounds cool right? Just "enable" it and be done? Unfortunately like I said, we're not quite there yet. You still need to configure some other parameters. Take a look at this screenshot:
Specifically, there are these 4 Dynamic Memory parameters:
- Startup RAM is the amount of RAM that Hyper-V will always give the host. Microsoft recommends that this is set to the minimum RAM system requirements of the guest OS.
- Maximum RAM is the upper limit of how much RAM the guest can grow to. This defaults to, and has a max value of, 64GB
- Memory buffer is slightly more complicated. It's the amount of extra memory that's reserved for the guest in addition to the committed memory that the guest VM is asking of Hyper-V. Think of it like the desired "extra" memory for that guest.
- Memory weight allows you to specify the importance of a VM in actual RAM allocation. The higher the memory weight, the higher the likelihood that VM will indeed get that memory. Memory weight will only kick in when the host is almost out of RAM.
Is Hyper-V Dynamic Memory any good for VDI?
Definitely! I love it.
I'll qualify by saying that I'm a ‘desktop virtualization guy,’ not a ‘server virtualization guy.’ (In this case that's a very good thing.) Let me explain: Desktop virtualization was hard enough when it was just Terminal Server, and the addition of VDI meant that things haven’t got any easier. If anything, it's made desktop virtualization harder. My personal opinion that VDI should be a lot easier and there are many steps that can be taken to achieve that, and making sure you use the RAM on your host as efficiently as possible is a great example of that which the Dynamic Memory feature gives you.
But while Dynamic Memory simplifies memory assignments, it creates new questions to answer like What should the memory buffer be? or How important is this VM? which are not that simple to answer. This is the part where it's great to be a ‘desktop virtualization guy’ because for VDI you shouldn’t care! :) There should be no reason why you'd need to change the memory buffer or the memory weight in a VDI environment. You can even keep the Maximum RAM left at its default (64GB) in most cases. So knowing that, Dynamic Memory comes really close to fulfilling the goal of memory being a completely shared and transparent resource like CPU.
That said, it may be worth experimenting with various Dynamic Memory configurations for your VDI environment. For example, you could provide Windows 7 virtual desktops with the minimum required memory (or even less!) to really put Dynamic Memory to work. You can also consider setting the ‘Maximum RAM’ to a lower limit: 2GB for example. This could possibly improve VM density since it limits the impact of VMs that eat up heaps of memory (for either good or bad reasons). Either way, make sure you watch the “Available Memory” performance counter in “Hyper-V Dynamic Memory Balancer” on the R2 SP1 Hyper-V host to make sure that you don’t overcommit memory on your host or else performance will plummet when you start paging too much. Some paging can be okay and safe (because the kernel is never paged out), but too much paging will definitely kill performance. Making the most of Dynamic Memory can really be worth your while. In fact Microsoft has seen improvements of up to 40% (!) in density for VDI workloads.
So it's all good?
It is for the most part. Without going into extreme detail on how Hyper-V assigns memory, it's important to know that Hyper-V talks to the guest OS to find out how much memory it actually needs and then allocates it as needed. Just be aware that if you run apps in your guest that query the OS for the amount of memory available on launch or use product installers that check the amount of memory before the install starts, these might cause a problem because sometimes they won’t continue when they ‘determine’ there's too little RAM available.
The reason for this is that Hyper-V allocates the extra memory when it's actually being requested by the OS, not when some random application queries from within the guest for the available memory. So if you do run into that situation, you'll need to set the minimum memory parameters of the guest to match the memory requirements of the product installer. In practicality this shouldn't be a big deal biggie because you'll probably use a ‘golden image’ of sorts so that install will be a one-time thing anyway. The problem becomes larger when an application queries for a certain amount of memory at launch and fails to start correctly if it doesn't find what it's expecting. The only option you have in that case is to set the minimum memory parameters of the guest to match the memory requirements of that application (but at the expense of limiting the efficiency of Dynamic Memory).
Finally you might also run into some weirdness with apps that do their own memory management. Some apps will grab all the memory they can in order to get the best performance. While this might be fine on a single-use PC, it's not such a good idea on a Dynamic Memory-enabled guest. The best option for these scenarios is to lower the Maximum memory for that VM, but again, this limits the efficiency of Dynamic Memory.
And of course, the fine print leads to one big caveat
It's important to know that in order to use Dynamic Memory, you need to upgrade not just Hyper-V (to 2008 R2 SP1), but also the in-guest ‘integration components’ (which are what allow the guest OS to be able to use the Dynamic Memory feature.) Unfortunately Dynamic Memory will only work on these guest operating systems:
- Windows Server 2008 R2
- Windows Server 2008 (SP2)
- Windows Server 2003 R2
- Windows Server 2003 (SP2)
- Windows 7 (Enterprise and Ultimate only)
- Windows Vista (Enterprise and Ultimate only)
That’s right. No Windows XP! And only the Enterprise and Ultimate Editions of Windows 7! (Although it really isn't that bad because you need the Enterprise or Ultimate Edition of Windows 7 to be able to do VDI anyway.)
Doesn't VMware ESX have this as well?
Yes and no.
VMware ESX has memory management techniques of its own (and has had most of them for a long time now). The most important techniques (great doc here) are Idle Memory Tax (IMT), Second Level Paging (Hypervisor swapping) and Memory Compression (new in ESX 4.1). Instead of scrutinizing all the different technologies VMware uses and how these compare to Dynamic Memory, let’s have a look at the goal of both Microsoft and VMware with their techniques.
Both companies have the goal to maximize the RAM usage on the host which is exactly what's needed for VDI. The most important difference between VMware's and Microsoft's approach in my mind is that Dynamic Memory allocates memory on demand (in ‘real-time’) whereas VMware’s memory management techniques pre-allocate memory and then uses several memory management techniques to reclaim unused memory. With VMware it's also easier to oversubscribe the physical memory of the host (note how I didn't use the word overcommit!) and I think that's a risk in most current VDI deployments. No matter how you slice it or dice it, when RAM is oversubscribed it introduces a higher probability of paging. This in return means a huge increase in IOPS. I guess it should go without saying that this is something you should avoid at all costs in VDI environments.
So should I move my VDI environment to Hyper-V now?
It’s interesting to see how the same questions keep popping up. In the past, every time a new version of Terminal Server came out, people would ask Do I still need Citrix? This question about Hyper-V feels the same and the answer is also the same: it depends. It depends on what you need out of your hypervisor. From the VDI perspective you should want to maximize the usage of the RAM on your host to its guests in the most flexible and efficient way. That’s exactly what Hyper-V 2008 R2 SP1 gives you. But of course it's also in ESX today. I don’t think Dynamic Memory will be the reason for people to abandon ESX en masse. I do think that, looking at memory management from a VDI perspective, Hyper-V fits the bill just as well as ESX does, if not better.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.