Tip

Hyper-V Dynamic Memory v. VMware memory overcommit: fish meets bicycle

Dynamic memory is Microsoft's attempt at answering one of the perennial problems in virtualization: how to efficiently assign memory to virtual machines that may not need it all the time.

    Requires Free Membership to View

Memory remains the critical resource people run out of first. Consequently, the lack of memory can be the source of low consolidation ratios. There's also pressure from application owners to demand as much memory for the application as possible, even when there's no need to allocate the amount of memory they demand.

In an ideal world, users would be able to assign a chunk of memory and have that memory consumed on-demand, as and when it is needed. For some time this wasn't the case in Hyper-V: If allocating VM 4 GB of memory when it was powered on, it took 4 GB of memory whether it was needed or not and the VM would not hand it back to Hyper-V until the VM was powered off. This would inevitably lead to lower consolidation ratios than those of Microsoft's rivals and made it difficult to assign memory in an efficient manner.

With the release of Hyper-V R2 Service Pack 1, Microsoft added dynamic memory support, a significantly different approach from the "memory over-commitment" employed by its main hypervisor competition, VMware ESX. Microsoft has long claimed it is "dangerous" to commit more memory to VMs than is physically present because all these VMs might demand their allocation simultaneously. Whether or not this is truly the case - we regularly use over-subscription in other areas of IT such as storage - Microsoft's stance has gained traction in the Microsoft community.

Dynamic memory essentially leverages the features of the guest operating system's management system to achieve its goal. Its roots lie in the capacity for most modern physical servers and operating systems to allow the addition and removal of memory on the fly. Dynamic memory piggybacks on this functionality, allowing Hyper-V to add or remove memory from a VM while it is running. Hyper-V presents a pool of free memory once the server has booted up. VMs are allocated slices of memory from this pool. If the Hyper-V host needs more memory itself, this can be increased in precisely the same manner. Dynamic memory is different from memory-overcommit because Hyper-V will refuse to grant more memory than is physically available in the pool. Memory is granted back to the system from the VM by leveraging the hot-add and hot-remove functionality from the guest operating system. Let's take a look at the requirements for dynamic memory to judge the merits of this approach.

First, Hyper-V and the existing Windows VMs must have Service Pack 1 applied to them. New versions of Windows 7 and Windows 2008 R2 can be installed with the Service Pack already present.

Second, enabling Hyper-V is done on a per-VM basis, with all VMs conforming to the static memory model by default.

Figure1: VM memory allocation (click to enlarge)

VMs are allocated a start-up amount of memory for the boot process. Because dynamic memory depends on a service and a driver being loaded in the guest operating system, an allocation of memory is needed just for the boot process (Figure 1). This is a Catch-22; there is no dynamic memory until the OS has booted, but for the OS to boot it needs memory. Most people recommend that users allocate a chunk of start-up memory to cover the boot of the OS and applications for their normal operation, leaving dynamic memory to handle "burst" demands. The official Microsoft line is that users only need to allocate enough start-up memory to cover what the OS demands.

The maximum amount of memory must be set to the VM; this sets a limit on the amount of memory a VM is allowed to have from the pool. The maximum this value can be is 64 GB.

Finally, users can configure a "memory buffer," an additional assignment of memory based on the amount committed to VM. This buffer is intended to offset any overhead caused by the dynamic memory's own process of allocating and de-allocating memory. So the actual allocation of memory is committed memory plus this memory buffer.

The default for this buffer is 20%, so if a VM was limited to 16 GB, and using 4 GB of memory, then approximately 820 MB (20% of 4 GB or in total 4.8 GB) would be assigned. As the memory demands inside the VM grow, the buffer proportionally grows until the configured maximum is reached. If a Hyper-V host becomes saturated from a memory perspective, this buffer can be sacrificed so the host can service demands for committed memory first. The buffer is used as a general cache to improve performance even when there is no pressure for dynamic memory to do its job.

Some would say that this buffer is merely adding a 20% memory tax on a VM in order for dynamic memory to function, while others would argue the tax is a worthwhile penalty for the added manageability the feature offers. Remember, dynamic memory only works for certain supported guest operating systems. There is some merit in memory management solutions that are completely controlled by the hypervisor, because they offer better compatibility with the typical range of operating systems running in most corporate data centers.

All memory management methods leave open the possibility for degraded performance if the IT admins configuring them don't monitor or manage them correctly. The important thing is to understand the benefits of the models, and take the right actions to monitor them with alerts designed to trigger the administrator to take  steps to avoid problems before they take hold.

ABOUT THE AUTHOR
Mike Laverick is a former VMware instructor with 17 years of experience in technologies such as Novell, Windows, Citrix and VMware. Since 2003, has been involved with the VMware community. Laverick is a VMware forum moderator and member of the London VMware Useroup. He is also the man behind the virtualization website and blog RTFM Education, where he publishes free guides and utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and 2011.

Since joining TechTarget as a contributor, Laverick has also found the time run a weekly podcast called the Chinwag and the Vendorwag. Laverick helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organized by the global VMware user group in North America, EMEA and APAC. Laverick published several books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.

This was first published in July 2011

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.