Five wrong reasons to prefer VMware ESX over Hyper-V
By Michael Pietroforte | 16 Comments | Permalink | Trackback | Previous | NextThe post entitled “Five Reasons Why VMware Virtualization is Better than Microsoft Hyper-V” on DABCC is already more than two weeks old. Perhaps I misunderstood some of the assertions in the article, but it seems to me that there are quite a few mistakes in it. I googled the topic to see if I had missed some essential news about Hyper-V; however, I wasn’t able to find anything that contradicts my view. So I decided to blog about it now because I am quite puzzled by the article’s arguments. Maybe you can tell me what I misunderstood.
I will reproduce the heading of DABCC article and sometimes a quote from Douglas Brown’s arguments, and add my comments afterwards.
1. Hyper-V is marketed as free but really isn’t.
Yeah it’s $28 bucks but that’s on top of a Windows 2008 License paid in full.
This is the first time I’ve heard that Hyper-V is marketed as free. At the moment, Hyper-V is just a feature of Windows Server 2008, like IIS7. Nobody ever said that IIS7 is free, so why should Hyper-V be free?
Anyway, the main mistake here is that Brown confuses two different products. According to this Microsoft press release, it is not Hyper-V, but Hyper-V Server that will cost $28. Hyper-V is a part of Windows Server 2008, and Hyper-V Server will be a hypervisor-based virtualization product which will be delivered by hardware vendors. As far as I know, it is not available yet.
I think what Brown wants to say is that ESX is cheaper than Hyper-V (not Hyper-V Server) if you add the licensing costs for Server 2008. However, the real price depends on many factors. It depends on the number of servers you want to virtualize and on the Windows server edition you run on the host system. For example, if you buy the Enterprise edition, you get 4 Windows Server licenses for the VMs and with Datacenter edition, you don’t pay anything for the Windows Sever guests. It also depends on the VM management product you will use. So I think there is no general answer to the question of which product is cheaper. It depends on your environment. If you intend to virtualize only Linux servers, you probably will pay less with ESX.
2. Hyper-V is not actually bare metal.
If Hyper-V isn’t bare metal, then ESX isn’t either. The only difference between ESX and Hyper-V here is that VMware uses a modified version of Red Hat Linux in the root partition and Microsoft uses Windows for this purpose. Of course, the advantage of Hyper-V is that it runs on every PC that supports hardware virtualization because there are more device drivers available for Windows. This is certainly an advantage of Hyper-V.
3. MS target market is low margin with little to gain because SMBs aren’t ready.
I doubt that Microsoft only targets SMBs. It is true that VMware ESX is technically advanced, but it is certainly wrong to put Hyper-V on the same level as VMware Server. VMware Server is comparable to Virtual Server. There is no doubt that Hyper-V offers better performance than VMware Server and also Virtual Server. Thanks to paravirtualization, it might even be faster than ESX in some environments.
However, my point is that when it comes to virtualization, Microsoft’s main product is not Hyper-V, but Virtual Machine Manager 2008. It was quite a smart move to support ESX in VMM 2008. Most virtualization experts agree that the hypervisor will only play a minor role in the upcoming battle between VMware and Microsoft. What counts are the management products. VMware is still leading here though. But we all know that Microsoft is not too bad at developing system management products.
4. Hyper-V ties the hypervisor back to the OS.
I already said it above. There is no real conceptual difference here between ESX and Hyper-V. If you worry about the overhead of a bloated Server 2008, you can run Hyper-V on Server Core. However, I suppose that Brown is referring to the fact that hardware vendors integrated the ESX hypervisor in their products, so he writes:
MS will have to release a true bare metal product to compete with VMware and they need to do it soon. I highly doubt they will though as Windows is integral to Hyper-V’s ability to do half of the things ESX does.
I wonder what reasons he has for these doubts. Didn’t Microsoft announce that they are already working on a “bare-metal” edition of Hyper-V in this press release?
5. Virtual Machine Density is a fraction of what is possible.
In this argument, he refers to the memory resource management features memory overcommitment feature of ESX. As far as I understand it, the main idea here is to virtually assign more memory to your VMs than is actually physically available. It is certainly a matter of fact that the amount of memory a server requires varies over time. Thus, with this technology you can run more VMs on a host than you can without it.
I must admit I have no experience with this feature, but I doubt that I would like to use it in a productive environment. The problem with any virtualization technology is that you run software in an environment for which it wasn’t developed. This can cause unforeseen problems. The farther you move away from a standard environment, the riskier it will be. And this technology sounds very freaky to me. I wouldn’t even configure virtual disks to grow dynamically in a productive environment. The main issue certainly is performance here. However, I also feel much more comfortable if VMs can rely on the resources that were assigned to them.
Anyway, memory resource management is only one feature of ESX that Hyper-V doesn’t have. There is no doubt that VMware is still ahead of Microsoft. The main point of my article is just that the five reasons given by Brown are not really the best ones. I do believe that there are good arguments for preferring ESX over Hyper-V.
I also do not want to rule out that some of my assumptions are incorrect. As I said before, one of the reasons why I wrote this post was because I am puzzled by the DABBC article. Please, let me know if you have any other information.




Subscribe via e-mail: 




One of the reasons I like Microsoft’s product is what you mentioned in #2. I can throw up a VM on almost any hardware, even a desktop, and the machine can be used for emergency purposes. Get that VM back online ASAP. That is a very big draw to me.
I’m an ESX admin (among all the other things I am ..) and I feel that your second paragraph of number 5 is a bit off, even with your disclaimer about having no experience .. VMware DRS which is what they call the resource managment features are widely used in production and one of the major points as to why ESX 3.x has been such a tremendous success.
You state that you ” .. feel much more comfortable if VMs can rely on the resources that were assigned to them”. Which is exactly what DRS lets you do – but on a whole new level. You are no longer tied to one physical box, you assign the resources needed on a cluster level, and DRS will suggest or even tie the VM to a host for you. Overcommitting memory is of course not something you do on a wide scale without thinking about it. You are still able to specify a minimum amount of “actual physical RAM” that should be reserved for the VM. What overcommitting could give would be in example memory headroom at the top for a group of VMs that do similar tasks. It’s a tool for you as an admin to use
And I might be nitpicking, but your comment about thin provisioning of virtual disks, again, it seems like bit of an overstatement ..
But in general, your argument about why we should be sceptical about virtualization makes sense. Test, then deploy
I think Michael raises fair points.
Jan, I didn’t get that Michael was referencing DRS as much as he was the whole memory balloon and memory overcommitment feature that seems exclusive to VMware. And if that’s what’s being discussed as opposed to DRS itself, the point is fair. I don’t typically use this feature in production either, though I do know that many people do. And realistically, unless your environment is highly similar, it doesn’t make sense to use it anyway. And you said as much as well. So the question is was it talking about memory overcommitment or DRS.
The statement about dynamic disks is fair as well in my book, though I have used dynamic disks in a number of Server and Virtual Server environments. Since the beginning, ESX was based on fixed disks, and didn’t offer dynamic disks. Why? It was enterprise and production ready, and using dynamic disks can cause performance issues, something most enterprises didn’t want to contend with.
I also didn’t get the sense that the post was about skepticism with virtualization, more about skepticism around the points made in the original post that he was commenting on… the 5 reasons why VMware is better than Hyper-V post.
Daniel, actually, it is one of the most important reasons for me. Unfortunately, Hyper-V doesn’t run on every desktop PC because their BIOS often don’t support x86 virtualization. I hope that hardware vendors will change this in the future.
Jan, sorry, but I didn’t mean DRS. DRS is certainly a very interesting feature even though it also seems to be a bit freaky if set to automatic mode. I made this clear now in the article. I was just talking about memory overcommitment. I do have some (negative) experiences with this technology. I was just not with ESX. Once bitten, twice shy. The same applies to dynamic disks. I prefer to spend a little more for memory and disks and let the machines do the work and not my brain. These rather freaky features usually need more time for preparation and human resources are often more expensive than hardware resources.
David, thanks for mentioning DRS. I wasn’t aware of the fact that “memory resource management” is associated with DRS. As to the dynamic disks, we were using them on VMware Server for some time and it was quite obvious that this feature caused performance problems under certain circumstances. After we started working with fixed disks, the problems were gone. We knew what kind of applications caused those problems, but we only work with fixed disks now. We just don’t have the time to figure out when it works and when not. And yes, I am usually pro virtualization although I am a bit more cautious now than in the beginning.
Memory overcommitment, you guys are right, I might have read into it too much. But now with the newly worded sentence it puts us on the same track
Memory overcommitment is indeed a “default feature” so if you are careless/incompetent in what you are doing you will most likely run into problems sooner or later. Best pracitice with ESX is still to use DRS (this is why I had a strong association .. ) to reserve an amount of physical RAM for those critical VMs.
You picked it up so I’ll comment again, like Michael says thin provisioning is not something that you “just do” and forget about. However, in larger environments, it does have merit, and it does work great. Not as a feature of VMware, but more as a storage virtualization solution provided by your SAN. The performance problems associated with this has largely been solved in that the SAN takes care of increasing the LUN in larger chunks rather than VMware increasing disk files in small increments. Because of this, to VMware it is all transparent. It will see a constant size LUN and VM disks just as a traditional SAN.
So I still feel that your number 5 is less accurate than the original number 5
Not having this possibility in Hyper-V is a loss.
Jan, I think we all agree on the memory thing now.
And I totally agree with you about DRS and its merits.
And you are right, with moving to the SAN and letting it take care of things on the disk side, many of the problems have been overcome.
I believe Microsoft is working fast and furious towards reaching feature parity with VMware. VMotion, DRS, etc. It will take some time, but they are at least identified and working toward that goal.
Good discussion. Thanks!
David
Hi,
I am sorry, but I seems to agree with the comparison between MS-Hyper & VMware at http://itcomparison.com/Virtualization/MShypervvsvi35/HyperVvsvmware35esx.htm
more than what you mentioned. I hope you can look at it and revert back. I know its using the demo version as a base for now, but I am really waiting till they evaluate the RTM.
Best Regards,
Digg1980
Regarding the bare metal comments -
ESX itself runs bare metal – the module bootstrapped by by the customized RHEL, but from there it is completely independent. RHEL remains running with small resources under its control as a console/management interface, but it could crash and burn as far as the hypervisor is concerned. ESX has direct access/control over physical devices/processor scheduling.
Digg1980, of course there are more things to consider here. My post was just a response to the article at DABBC and nothing more.
Andrew, I didn’t deny that ESX runs on bare metal. The interesting question is whether there are any relevant differences between Hyper-V and ESX.
Both ESX and Hyper-V are based on a hypervisor running on bare metal but uses 2 different architectures. The main difference as Andrew states is that once ESX is up and running the RHEL based servcie console can actually be unavailable and the VM’s on the ESX host will still run even though they will be unmanageable.
In Hyper-V the VM’s or child partitions are dependant on both the parent partition and the hypervisor. If the parent partition is not available and working then the guest VM’s will not work at all.
Tage, thanks for clarifying this. I wonder how Hyper-V Server (the up-coming bare-metal version of Hyper-V) will work then.
I run ESX at work, have been doing that for a few years now and I feel that a few points are missing in this discussion.
What ESX does that Hyper-V does not do and why it matters.
VMotion, to move a virtual server from one hardware to another is vital for uptime. We can upgrade the hosts without any downtime for the applications.
Storage VMotion, to migrate from one storage solution to another. Now we are truly independat of the hardware when we can replace all the hardware on the fly.
Memory sharing. Normaly like with HyperV a virtual machine takes 1gb of memory, always. With ESX if you create one Windows VM and give it 1gb of memory it will take 1gb of the host. The next Windows VM you create will not take that much since both VM’s share alot of the same stuff they need to store in memory which leaves the second VM maybe requireing only 800mb.
Memory balooning. If you add memory balooning and sharing you have some very effective use of memory. You dedicate 1gb memory for the first machine, it only uses 500mb, so it only takes 500mb from the host. The second might only need 250mb from the host because of memory sharing. That way you can put 4gb worth of VM on a host that has maybe only 3gb of memory.
DRS. This I use alot and its all automated. You have a cluster of 4 hosts or so. One host is up to 80% of its memory in use and you then over commit the memory to 120%. As soon as it goes over the threshold the DRS will VMotion the machines to a new host.
And finaly HA (dont know if HyperV offers this) If one host in the cluster goes down the VM’s all reboot on new hosts automaticly.
Its a sweet life compared to bare metal
And about how the Linux kernel is used. The hyperwisor sits on the hardware and the linux thing sits as a VM on top of the hyperwisor just like any other vm.
Something from me. I am keen to have a look at Hyper-V and Hyper-V server though to be honest will stick with VMWARE Enterprise until MS gets similar advanced functionality.
A couple of things about licensing.
The buy one physical license use it for 4 virtual machines is also the case where it runs under VMWARE. I have checked this myself with MS licensing.
However I am from an EDU and I can tell you that VMWARE do not offer the attractive dirt cheap prices MS would offer.
Regarding the advantages published on ESX advanced memory capabilities such as Memory Overcommitment, Transparent Page Sharing (TPS) and Balloning it is important to mention that they come at a cost which is significant memory overhead per VM.
Depending on the amount of memory assigned to the VM, number of vCPUs and whether it is an x86 or x64 VM this overhead can be more than 100 % !!!(http://pubs.vmware.com/vi301/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_advanced_mgmt.11.18.html)
Even though TPS might reclaim some of this memory overhead if the VM’s on a given host are fairly equal, the net effect might not be better than Hyper-V and could even be worse after DRS have had time to shuffle VM’s around.
My point here is that if you do not design your environment correctly, right size your VM’s and place them intelligently the advanced memory features might not do you any good in the overall picture.
Hyper-V has HA or host cluster functionality using the Failover Cluster feature of Windows 2008.
VMOTION is still a feature that Hyper-V lacks although the quick migration might be ok for a lot of customers. With quick migration the downtime is faily limited but if it is a problem, then the patching of the host servers will just need to be done during the defined maintenance windows. For most customers it will not be that big an issue as the host servers do not need to be patched that often.
Where VMOTION is really beneficial is in relation with DRS to distribute the workload in a cluster. However, at present DRS only focus on CPU and memory and does not take Network and Disk I/O workload into account.
Hyper-V does not have a DRS functionality yet, but the PRO feature of SC/SCVMM will deliver that in the near furure and seems to be a much more powerfull platform than DRS. However, in order to have a real DRS capable system Hyper-V need to have Live Migration capabilities which will probably come in the first service pack. After all it was on the feature list for Hyper-V for a long time but was skipped with some other features because MS had to release the product on time.
Regarding the announced Hyper-V server product SKU I have not yet been able to find any official details on this, but it will most likely be based on a stripped down and locked version of Windows Server 2008 Standard Edition.
Regarding: 2. Hyper-V is not actually bare metal:
ESX isn’t build upon any RedHat release what so ever. VMkernel which is the operating system runs on top of the hardware and then ESX (not ESXi which only consists of the VMkernel part) uses a VM (the Service Console) build upon Redhat Enterprise server for interaction / adminisrtation of the VMkernel.
Magnus, read this Wikipedia article: “Up through the current ESX version 3.5, a Linux kernel is started first[5] and is used to load a variety of specialized virtualization components, including VMware’s ‘vmkernel’ component.”