Microsoft Dynamic Memory rivals Citrix, not VMware

Think Hyper-V Dynamic Memory is Microsoft’s answer to VMware's memory overcommit? Not so fast. Mike Laverick writes that it actually has more in common with Xen than ESX.

As the release of Service Pack 1 for Windows Server 2008 R2 nears, you can expect the virtual machine management...

debates to flare up again.

The main topic this time around will be how Microsoft’s new Dynamic Memory feature compares to VMware’s memory overcommit. The annoying reality is that Dynamic Memory and memory overcommit are actually very different technologies designed to solve different underlying challenges in each vendor’s hypervisors. As such, it will be difficult to compare them since, philosophically, they spring from different challenges and approaches.

As we’ll see in this article, Microsoft Dynamic Memory actually has more in common with Citrix’ Dynamic Memory Control (DMC) introduced in the 0.5 release of its Xen Cloud Platform (XCP).

VMware memory overcommit -- not like the others
Memory overcommit basically allows the creator of a virtual machine (VM) to allocate more virtual memory than what might be physically present. For me, this is not unlike thin provisioning in a modern storage array. So in the same way that I can create 10 x LUNs/volumes that are 2 TB in size even though my array only has 6 TB of storage, I can similarly create 10 x 2 GB of RAM virtual machines despite only having 6 GB of physical RAM.

VMware’s ESX host delivers the physical memory on demand and memory overcommit depends on the assumption that not every VM will need this memory all the time. If they did, then excess swap activity would take place. As with storage overcommit, there are potential dangers if you don’t monitor your actual memory usage against the physical resources, but the advantage is you don’t have to buy expensive physical RAM that you may never need.

It’s this lack of memory overcommit functionality that caused many industry experts to dismiss the first R2 release of Microsoft Hyper-V. Prior to Hyper-V R2 SP1, if you allocated 4 GB of RAM to a virtual machine, it would need to find 4 GB on the host whether it needed it all or not. Dollar for dollar and pound for pound, this meant a lower consolidation ratio on Hyper-V compared to the ESX platform.

A better comparison? Microsoft and Citrix
The rationale behind Microsoft’s and Citrix’ approach to dynamic memory management is more about easing administration than trying to increase the consolidation ratio on a host. It really comes down to addressing the thorny question of, “How much memory should I allocate to a VM?”

In the world of VMware, if you failed to allocate the right amount of RAM you would simply use the hot-add memory feature. Neither Hyper-V nor XenServer currently have this feature, though both attempt to address the issue using dynamic memory.

You can add more memory to a virtual machine by powering down the VM, increasing the allocation and then powering the VM back up. This is what VMware administrators had to do until vSphere 4, which now includes a hot-add of RAM feature. This wasn’t a major problem for some shops, however, since ESX delivered the memory on-demand. This made it possible (though somewhat risky) to over-allocate memory and avoid the need to claim a maintenance window.

As for dynamic memory, my friends at Citrix recommended an excellent article that explains the advantages of this approach. The article, which was probably written before the advent of ESX 4.1, talks about the act of powering off VMs to add more memory. Since I could not have put it better myself, I’ve added italics to emphasize the key sections:

“[Dynamic Memory Control] allows you to change the amount of host memory assigned to any running virtual server, without rebooting it. In virtual server environments without DMC, it's necessary to decide in advance how much memory to assign each virtual server. Once a virtual server is running, its memory allocation is fixed, and it's not possible to change [it] without rebooting. Rebooting production servers can be painful, so administrators are left with a choice between:

    • Allocating a large, fixed amount of host memory to each virtual server: This decreases the risk that the virtual server will run out of memory, but leaves less host memory available for other virtual servers.


    • Allocating a small, fixed amount of host memory to each virtual server: This leaves more host memory available for other virtual servers, but increases the risk that the virtual server will run out of memory.

  • DMC frees you from having to make a fixed choice about how much memory to assign to each virtual server. Within certain limits, you can reduce or increase a virtual server's host memory allocation without rebooting the server.

  • This means you could start a virtual server with a small amount of host memory, but plan to add more later as necessary. Alternatively, you could start your virtual server with a large amount of host memory, but reduce this amount later on if it turns out that it needs less than you expected.”

If you look at “dynamic memory” in this context and check out Microsoft’s current Dynamic Memory dialog box for the Hyper-V R2 SP1 beta (below), it should help further clarify the different approaches by the vendors.

Figure 1. Dynamic Memory dialog box for Hyper-V R2 SP1 (click to enlarge)
Dynamic Memory dialog box for Hyper-V R2 SP1

By default, Hyper-V R2 Service Pack 1 allocates a standard of 512 MB, which is just enough memory to load most operating systems. The default maximum is 64 GB, and it’s recommended that you lower this number down if your applications are untrusted and could contain memory leaks that would demand more and more memory.

The slider bar for the Memory Buffer allows you to reserve some working memory. So if you gave a virtual machine 10 GB of memory with a buffer of 5%, there would be an additional 512 MB buffer. To put it another way, if the VM used all 10 GB there would be 512 MB of additional memory in the buffer to account for this unexpected burst of memory use.

Finally, the Memory Priority setting works in a similar way to VMware’s share value. But whereas VMware settings are configurable on a resource pool or from a table, Microsoft’s priority settings are done on a per-VM basis, which could result in quite a bit of administration and even some nifty work with Windows PowerShell. In Ben Armstrong’s demo (sidebar above) he uses a PowerShell script to switch a large number of VMs into Dynamic Memory mode.

In the dialog box, it’s possible to set a minimum/maximum value for memory. The minimum value is used to set a guarantee of RAM to the virtual machine at power on, with the maximum being a fixed limit on the total amount of memory assigned. At first, this would appear to be very similar to the “Reservation” and “Limit” parameters that can be set in VMware, as it allows the administrator to grant more memory to the VM(s) than is physically present in the server. Its true agenda, however, is not so much that of increasing consolidation ratios (as is the case with VMware’s memory overcommit) but addressing the lack of a hot-add RAM feature in the Hyper-V and Xen kernels.

Similarly, if we look at a Xen implementation from Citrix, we’ll find a very similar UI (below). Citrix XenServer also has an SDK API that allows administrators to write their own “wrapper” (assuming they have the skills to do this!) that is outlined in the Citrix KB article CTX12544.

Figure 2. Memory management with Citrix XenServer (click to enlarge)
Memory management with Citrix XenServer

Dynamic Memory will be a welcome addition to Hyper-V, but if you ask me, comparing VMware memory overcommit to Microsoft Dynamic Memory is like comparing chalk to cheese. I suspect and hope that Microsoft will not claim that its Dynamic Memory feature is intended to rival memory overcommit. Otherwise, some serious U-turning will need to take place.

You can follow on Twitter @WindowsTT.

Mike Laverick (VCP) is an award-winning expert and author who has been involved with the VMware community since 2003. He is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users.




Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:









  • Virtual desktop security guide

    To secure virtual desktops, consider antivirus, certificates and network vulnerabilities. Just remember, VDI doesn't always ...

  • Guide to low-cost desktop virtualization

    In this guide, learn to virtualize desktops without spending more than you would when deploying PCs, and what VDI vendors are ...

  • VDI pilot project guide

    A VDI pilot project should start with a VDI project plan. Know what pitfalls to avoid and test product options to achieve a ...