When myth busting goes wrong and becomes a myth to bust it self

Today I saw a video posted by Microsoft that should have shown a number of myths busted about VMware ESX. Unfortunately it turned out to be wrong on a number of points and it made me angry, why can’t we play it fair. With Hyper-V, I think MS has quite a good product for a 1.0 version, but these marketing campaigns that try to tell the world that Hyper-V is mature already, really come down the wrong way on me. Why not just admit that in version 1.0 it is no match for Xen or ESX, but definitely a good start and tell about the improvements you make for R2? When I see a video like this, I can’t help it and I just feel the need to correct it.

In the video they have 10 myths they want to bust, 10 points on which VMware is wrong when comparing ESX to Hyper-V. Some of these busts are not quit correct. Therefore my list:

1) Microsoft has no live migration.

According to the two gentlemen in the video Microsoft does have Live Migration: “In Microsoft Windows 2008 R2 that is coming out really soon we have Live Migration”. Correct !!! In R2 there is Live Migration and it works just like VMware’s VMotion. Busted !!! Well, no not exactly, because R2 is still in beta and there is no official release date yet. Last time I heard R2 was coming early 2010, which is still 8 months away. So, at THIS moment (April 2009), Hyper-V has no Live Migration feature.

2) Clustered file systems

The gentlemen again talk about a Windows 2008 Release 2 feature. And again the correct answer should be: “No we don’t have that in Hyper-V 1.0, but we do have it in Release 2.”, but instead they check this as a busted myth. Strange line though: “so all these issues are addressed in Release 2”. Unfortunately, no points on this one for them.

3) Hyper-V is a 1.0 product.

The gentlemen claim that VMware says Hyper-V is a version 1 product and it is not scalable, not mature, not fast enough. They counter this by giving examples on how many Hyper-V installs that are running at Microsofts data centers and that for example the technet website is completely running on Hyper-V and they have seen situations in which 4500 VMs were running on Hyper-V. Well, this doesn’t say anything about reliability, stability and scalability. If you have all systems run 1-on-1 (1 VM on 1 Hyper-V host) you can also have 4500 VMs running and I bet it is quite stable. Now, of course I don’t believe that they were actually running all those systems 1-on-1, but I just want to make the point that this doesn’t proof that Hyper-V is scalable, etc, etc. If you want to bust a myth, please bring some better arguments.

4) Low performance

I have to admit on this one that performance on Hyper-V does look much better then I would have expected. Only trouble I see in all these tests, they never give all the details on how and what. Please someone show us a real good in-depth report that I could reproduce in my own lab, which compares all the top 3 hypervisors at this point (Hyper-V, Xen and ESX).

To me, I think, it is not really myth busted, but since performance does seem to keep up with the rest of the hypervisors, let’s call this: Myth busted.

5) Footprint

The myth they want to bust here, is that the difference in footprint isn’t that big, plus they raise the question whether the footprint really matters. I have to agree with these guys that if you use a disk to install ESX or Hyper-V on, it doesn’t matter that much if the hypervisor or OS with hypervisor uses just 2 GB or 10GB of disk space. When buying a disk these days, the smallest is 36GB, maybe 18GB if you’re lucky and it doesn’t matter because in most installations, you consider that local disk as “lost”, you won’t be hosting VMs on it. It is a different story however, when you want to run disk less servers and boot the hypervisor from USB (USB stick or internal USB chip), then size does matter.

What the memory footprint is concerned once the hypervisor is loaded, I do think they again have a point. By default, ESX uses 272MB of memory to load kernel, console and management agents. But most admins will already have set the memory they assign to the Service Console, to a value of 800MB. Now, when you install Windows 2008 core (not the R2 release) with Hyper-V installed, you will be running about the same amount of memory usage.

Big question however is, is this really a myth? Does the end-user of one of these hypervisors really care?

6) Broad hardware support

Now here comes the nitpicking. The gentlemen show you a screenshot of the VMware website and tell you, VMware is comparing Citrix and VirtualIron’s HCL but not Hyper-V’s HCL. Technically these two guys are correct, but if you take a closer look, VMware states: “Microsoft claims that they have a very big HCL, because they can use the same Windows Server 2008 drivers for Hyper-V deployments. However, Windows drivers have traditionally been the major root cause when it comes to Windows instabilities”. Now I would rather have the gentlemen counter that statement, instead of just claiming they can run Hyper-V on any hardware.

Another point that should be clear, is that most drivers from other vendors are not optimized for Hyper-V, not optimized for performance. I can remember some nics I installed, that had a 45MB driver included, which had all those great extra features, that I never asked for and probably don’t do any good to system stability. Also, the set of nics you can use if you want to trunk VLANs and automatic failover of links, is very limited. Which actually brings you to a rather short list of hardware that is truly compatible with Hyper-V.

In other words, this myth is definitely NOT busted.

7) Management

They say “VMware is only talking about Virtual Machine Manager, they (VMware) are not talking about Systems Center”. What the gentlemen are trying to say here is that one shouldn’t compare vCenter to Virtual machine manager, but rather to the complete Systems Center suite. It is kind of difficult to really get to the point of where this is about, because I’m not sure what VMware claim this is all about.

8 ) Memory Over-commit

The statement for the gentlemen is that memory over-commit is only useful in a very few scenario’s and they haven’t seen the 2 to 1 ratio’s VMware talks about. If you want to have a real technical discussion, then they are right in that memory over-commit doesn’t give you the 2 to 1 ratio. But, what they forget to mention is that memory over-commit is just one part of the memory savings techniques, the biggest memory saver is “transparent page sharing”. These two techniques work together as one and together they can give you a 2 to 1 ration or even more (seen with some of my customers).

Another point is the memory assignment for each VM they want you to make. Their statement is that if you monitor your VMs closely and give them just the right amount of memory, you don’t need to over-commit. Well, to be honest, I never give 893MB of RAM to a VM, it will probably get 1GB or maybe 1,5GB just to prevent the guest OS from swapping to its internal pagefile when a process suddenly has a memory spike. If you have a host that runs 50-60 VMs, that is quite some memory you’re wasting if there wasn’t memory over-commit. Plus, it saves me a lot of time consuming monitoring to find out if the VM needs 893MB or 900MB or 1150MB of RAM.

And there is more. There is a big difference in over-commit and over-commit. I have explained this in other posts on my blog already, but I’ll give a short explanation here: When you assign more memory to the VMs then present in the host, but always make sure that the memory needed by the VMs doesn’t exceed the amount of physical memory present, you are over-committing and you are saving memory. You have no performance lost when you do memory over-commit the right way.

9) Lower cost per VM

Always a very difficult point: the cost per VM. Calculating the cost of a virtualization solution is always difficult, because it fully depends on how much virtual machines or applications you want to run and in the end, how many physical hosts plus licenses you are going to need for that. If product A is quite expensive but makes it possible to run twice as much VMs per host and you therefore have to buy less licenses of product A, you might be cheaper in the end compared to buying much more licenses of cheaper product B.

Now, in the first part of myth bust number 9, they again use the memory over-commit to argue that VMware is cheaper then Hyper-V, but as pointed out on myth bust number 8, memory over-commit does work and does save memory and therefore in the end memory over-commit will cut down the number of needed hosts.

In the second part of myth bust number 9, they talk about how VMware needs the higher consolidation ratio to get the price near Hyper-V’s price. Hmmm, what is so bad about that? Wasn’t virtualization for a large part about consolidation? And, like I stated above, if higher consolidation ratio saves me buying a number of hosts and therefore licenses, what is wrong with that.

Never the less, I still find it difficult to compare prices between the two because a lot depends on this consolidation ratio, which is totally depended on the number and types of applications you are running in your data center. Of all the performance test I have seen, they where all difficult to reproduce and difficult to compare. What the business really needs, is a benchmark for virtualization. This way businesses can see how many VMs product A can run on one host, compared to product B and then do the math for their own organization.

10) You Need VMware Virtualization

This is getting really annoying because of the assumptions being made…. First statement of the distinguished gentlemen is about the layers of Hyper-V compared to VMware ESX. The guy on the left says: “With VMware you’re dealing with four layers. You got the hardware, the VMware layer, the Operating System and the applications. With our solution (Hyper-V) you have three layers. You have got the hardware, you have the Operating System and the applications.”. Excuse me? In Hyper-V you have exactly the same layers VMware ESX has, there is just a difference in which component runs in what layer. Luckily not everyone at Microsoft is as badly informed, see: http://technet.microsoft.com/en-us/magazine/2008.10.hyperv.aspx, Figure 2. Being wrong on this statement makes this whole last myth bust totally incorrect and with that another myth bust turns out to be a myth it self.

Summary

Personally, I’m getting really tired by these “commercials” in which company A compares its product to company B and makes big mistakes in the comparison. I can live with commercials that say that pepsi is better then coca-cola, I can live with a commercial that says buy Hyper-V instead of VMware but I always have problems with seeing how Microsoft is constantly spreading this kind of commercials that are plain wrong. Why is that? Does Microsoft really have so much credit with their customers, does Microsoft think their customers don’t look any further then only Microsoft’s word? If they really need this to compete with VMware, why not bring out R2 very soon? Or maybe release a Hyper-V 1.5 version that only adds Live Migration and Clustered File System? This will make Hyper-V come closer to VMware ESX, especially in the SMB segments where the higher consolidation ratio’s don’t make such a big difference since they will not be running that many VMs in total.

I do like a good hypervisor war, the more my customers can choose from, the more interesting work I have. But please, keep it a clean fight, because this is costing me many phone calls explaining why Hyper-V is not the right choice, yet.

The original Microsoft post: Top 10 VMware myths video with David Greschler, the “Director of Virtualisation Strategy” for Microsoft and Edwin who is technical product manager for the same group.