VCritical » memory overcommit

Hello Dynamic Memory?

Eric Gray — Tue, 02 Feb 2010 04:52:40 +0000

Looks like I was on to something a few weeks back when I showed how Microsoft had tried — but failed — to implement a feature that would allow Hyper-V R2 to accommodate the use of more virtual machine memory than available on the underlying physical host.

A screenshot of Dynamic Memory configuration in a post-RTM build of Windows Server 2008 R2 has surfaced in an article at Softpedia.

Listen… Do you hear that?

It’s the sound of Microsoft Virtualization curbing their criticism of memory overcommit.

Hat tip to Aidan Finn.

Hyper-V More Stable, Just as Mature as VMware vSphere?

Eric Gray — Thu, 21 Jan 2010 23:29:13 +0000

I just read a fascinating article on the Microsoft Virtualization blog from a special guest poster responding to the recent InformationWeek article that cited 9 reasons Hyper-V is not ready for the Enterprise.

The author worked extra hard to refute all 9 points — but I do admit being somewhat distracted by the gratuitous use of VMWare throughout. Evidently, proofreading — unlike immeasurable technology and services discounts — is not one of the benefits extended to guest posters these days, which is a shame.

The Microsoft Virtualization MVP tries to use most of the pages from the playbook, such as memory overcommit FUD:

Relying on a host to overcommit memory to support failover hosts is potentially dangerous and incorrect oversubscription leads to all VMs suffering from performance.

Have you ever had a VM suffer from performance? I have, and believe me — it’s not pleasant.

But here is a familiar line:

… I would never over commit my VM hosts in production.

Where have we heard that before? I almost forgot to mention that this guest poster is none other than Chris Steffen — the star of that now-infamous CIO Magazine article who once called VMotion a “gimmick” and said:

I don’t know what kind of environment other than QA or development, or in a staging environment you’d want to do [live migration], but it’s not going to be in any production environment I’m responsible for; it’s not going to be any environment dependent on any kind of SLA or performance requirements. The justification for the inherent risk just isn’t there.

But what does Mr. Steffen say now that Hyper-V has Live Migration? About what you’d expect — and more:

Also keep in mind that using the System Center suite, the Microsoft solution can Live Migrate VMs to other hosts due to situations that VMware servers cannot even monitor, such as CPU Power, Power Supply Failures, and Fibre Channel congestion.

There are a number of other gems in this convincing piece. Did you know:

Hyper-V is more stable than and at least as secure as VMWare [sic]
vSphere is just as new as Hyper-V

Yep, there is a full-day supply of Kool-Aid in that guest post.

Nice work, Microsoft Virtualization team. I’m not so sure this sort of thing helps your cause — please keep it up.

The Truth About Hyper-V Memory Overcommit

Eric Gray — Wed, 13 Jan 2010 13:20:05 +0000

The ability to assign more memory to virtual machines than physically available on a host is called memory overcommit and is a major factor that contributes to higher VM density — running more virtual machines per host increases efficiency and reduces cost. VMware ESX has provided this feature for multiple generations, giving it an advantage over competing hypervisors.

The Cost Per Application Calculator makes it clear that investing in VMware vSphere 4 significantly reduces your datacenter hardware footprint and associated costs. Scott Drummonds, the VMware performance expert, recently explained how memory overcommit is the only way to effectively use all of the physical RAM in a hypervisor.

Each time this topic comes up, Microsoft revs up their marketing machine and responds like this:

Hyper-V is free, use your money to buy RAM upgrades instead of VMware vSphere licenses
Memory overcommit is risky, VMware tells customers to turn it off anyway

The truth is that Hyper-V will have memory overcommit the moment Microsoft figures it out. If that day ever does come, watch the messaging quickly change to the familiar, “our customers asked us to implement this…” line.

Why is it fair to make such a bold claim? Two words:

Dynamic Memory

It’s a little known fact that some of the early releases of Hyper-V R2 actually had a feature that allowed administrators to assign more RAM to virtual machines than was physically present on the host — “Dynamic Memory” a.k.a. memory overcommit.

We can look back and see what bloggers like Mark Wilson had to say:

Microsoft also spoke to me about a dynamic memory capability (just like the balloon model that competitors offer). I asked why the company had been so vocal in downplaying competitive implementations of this technology yet was now implementing something similar and Ward Ralston explained to me that this is not the right solution for everyone but may help to handle memory usage spikes in a VDI environment. Since then, I’ve been advised that dynamic memory will not be in the beta release of Windows Server 2008 R2 and Microsoft is evaluating options for inclusion (or otherwise) at release candidate stage.

And this blog provided more detail on the implementation:

In Hyper-V 1.0, physical memory was hard allocated to the VMs, but in 2.0 the pool of memory is dynamically allocated and removed based VM usage with no service interruption. Dynamically allocating memory to VMs can drastically improve host consolidation rates.

Hyper-V 2.0 VMs are configured with an initial RAM setting (how much the machine boots with) as well as minimum and maximum RAM values. Hyper-V then adds RAM using the Hot-Add function, and removes it using a balloon driver (for supported OSes).

For the visual learners in the crowd, take a look at this VM configuration dialog:

Note that this is nothing like Transparent Page Sharing in VMware ESX — Hyper-V VMs would actually be reconfigured using hot-add memory, so the guest operating systems must cooperate.

In an interview with Steven Bink, even Bob Muglia acknowledged the need for overcommit:

We talked about Vmware ESX and its features like shared memory between VMs, “we definitely need to put that in our product” later [Muglia] said it will be in the next release. Like hot add memory, disk and nic’s will be and Live migration of course, which didn’t make it in this release.

By the way, hot-add memory didn’t make it into Hyper-V R2, either — VMware ESX 4 has it today.

Quick Memory Overcommit?

Evidently, dynamic memory was not even up to the rigorous “Quick” standard and was dropped from the release train. Perhaps in some future edition of Hyper-V, Quick Memory Overcommit will be offered — with just a few seconds of VM downtime as RAM allocation is dynamically adjusted. But that’s just speculation.

Sour Grapes

Instead of finding a way to implement memory overcommit in Hyper-V R2, Microsoft has taken the alternate approach of attacking VMware and declaring the feature unnecessary, unsafe, or too expensive.

The fact is that memory overcommit is an extremely valuable capability and VMware ESX has had it all along. Some of the Linux-based hypervisors are starting to figure it out. Until Hyper-V finally adds the feature we’ll continue to hear how easy it is to simply buy more RAM.

How long can you afford to wait?