Hyper-V Dynamic Memory vs. VMware memory overcommit
Memory allocation can be a guessing game in virtualized environments. Hyper-V Dynamic Memory and VMware memory overcommit tackle the problem in different ways.
Many virtualization administrators have to face down the complex task of memory allocation in their environments. Regardless of whether an organization uses VMware vSphere or Microsoft Hyper-V, physical memory has historically limited the number of virtual machines (VMs) that a physical server can host. But Microsoft's Hyper-V Dynamic Memory and VMware's memory overcommit features allow admins to maximize VM density on their servers.
Memory overcommit allows a VM to use more memory than the physical host has available. Let's say you have a host with 2 GB of memory and run four VMs on it with 1 GB of memory each. The memory is overcommitted because there's more virtual memory than is physically available. Admins can therefore maximize the number of VMs that a host server can run without as much concern for physical memory limitations.
Without memory overcommit, the amount of memory allocated to a VM was typically the maximum amount that the machine was anticipated to need. But in reality, a VM often consumes much less memory than it reports that it needs. This is a waste of physical memory space, and it limits the number of VMs that you can run on a server. For instance, say you have a Hyper-V server with 8 GB of RAM. You can probably host about three VMs on the server -- allocating 2 GB each and reserving 2 GB for the host operating system -- even though the server has sufficient CPU and disk resources to easily host more VMs. The memory is the limiting factor.
Hyper-V Dynamic Memory addresses this issue by including an option to "buffer" the machine with extra memory. But VMware includes an actual memory overcommit feature. Both memory allocation methods provide dynamic allocation across all VMs on an as-needed basis.
VMware memory overcommit
For quite some time, VMware has included a memory overcommit feature. The underlying technology is the Idle Memory Tax (IMT), which assigns values to "shares" of memory. To understand how IMT works, you have to understand the concept of memory shares. Essentially, VMware treats memory as a sharable resource, and each megabyte of memory is considered an individual share. Therefore, a server with 16 GB of RAM has 16,384 shares of memory, not accounting for server overhead. IMT assigns a higher value to unused memory shares.
VMware memory overcommit works by taking shares from machines that are not using them and allocating those shares to other VMs where they can be better used. This process happens dynamically, relieving admins of static memory allocation. The host checks share usage every 60 seconds and makes adjustments as necessary by allocating memory to the VMs that need more at the moment. It is also worth noting that ESX will not remove all of a VM's unused memory. The VM is allowed to retain 25% of its unused memory as a cushion in case it suddenly requires more memory.
Imagine, for example, that a server has 16 GB of RAM available to each VM. Suppose that one of the machines is an Exchange 2010 mailbox server that wants to claim all 16 GB for itself. But you have an FTP server that needs only 1 GB of memory to operate. For the sake of demonstration, let's pretend that we allocate a full 16 GB to each VM (which equals 32 GB total).
The FTP server has been allocated 16 GB, but uses only 1 GB. Therefore 15 GB (15,360 shares) of memory are not being used. With its memory overcommit feature, VMware ESX allows the VM to keep 25% of its unused shares but removes the extra 75%, or 11.25 GB (11,520 shares).
The parameter of 25% is adjustable, but VMware advises against changing it. Memory overcommit makes memory allocation easier with VMware's dynamic method.
Hyper-V Dynamic Memory
Microsoft does not allow memory overcommitment, but takes a different approach to dynamic memory allocation. Before Hyper-V Dynamic Memory was released in the new Hyper-V R2 Service Pack 1, admins had to statically allocate memory.
Suppose, for example, that you allocated 4 GB of memory to a VM running on Hyper-V. Of that 4 GB, let's say the VM used only 2 GB. When you start a VM, Hyper-V checks to make sure that 4 GB of physical RAM is available. If so, that memory is "locked" so that it can be used only by the specified VM. If 4 GB of memory are not available, the VM won't start, even if the 2 GB that the virtual server actually requires is available.
Hyper-V Dynamic Memory works similarly to VMware memory overcommit in that it reclaims memory from VMs that are not using it. The host dynamically distributes memory in one-second intervals. Microsoft even lets you configure virtual memory settings to control the host's memory allocation behavior. The difference between Dynamic Memory and VMware memory overcommit is that Microsoft openly encourages administrators to set their own memory thresholds. By doing so, admins can achieve maximum VM density on a server as well as maximum performance.
Hyper-V also provides a buffer, just as ESX reserves 25% of unused memory as a buffer against sudden increases in required memory. The difference is that Microsoft includes a slide bar so admins can control the percentage of additional space that each VM reserves as a buffer. This reserved memory in Hyper-V is part of the host's total available memory, whereas VMware memory overcommit allows you to allocate more memory than is physically available.
Another difference between the two features is that Hyper-V admins can set the amount of memory that the VM is allocated at startup as well as the maximum amount of memory that a VM can use.
Finally, Microsoft allows VMs to be prioritized in terms of memory usage. That way, when memory contention occurs, high-priority VMs receive memory first. It's also necessary to monitor virtual memory levels in Hyper-V, because memory contention can force a VM into an out-of-memory state if not enough memory is available when a VM needs it. The Manager Console reports on available memory for each VM to help you manage memory allocation on Hyper-V.
Choosing a memory allocation method
Memory overcommit makes it possible to reduce costs by increasing the number of VMs hosted on each physical server. In doing so however, administrators must take care not to overcommit resources to the point that performance is affected.
More on memory allocation
- How virtual memory allocation works with Hyper-V Dynamic Memory
- How to monitor virtual memory with Hyper-V Dynamic Memory
- virtual memory settings in Hyper-V Dynamic Memory
- Virtualization causing server memory allocation issues
So which memory allocation method should you use? Vendor rivalry aside, VMware's and Microsoft's memory overcommitment features are similar enough that choosing a virtualization platform based on memory overcommit capabilities alone isn't prudent. In the real world, both virtualization platforms deliver similar performance when properly tuned. Therefore, my advice is to keep using whichever platform you currently use. The benefits gained from switching vendors -- at least in terms of memory overcommitment -- are probably not worth the cost that you incur in making the switch.
The only real difference between Hyper-V and VMware memory allocation is that Microsoft provides additional settings to customize startup RAM, maximum RAM and priority VMs. But both options allow for more precise memory allocation in your virtual environment.
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award seven times for his work with Windows Server, IIS and Exchange Server. He has served as the CIO for a nationwide chain of hospitals and healthcare facilities and was a network administrator for Fort Knox. You can visit his personal website at www.brienposey.com.
