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.

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.

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.

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.

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.

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.

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.

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

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

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, 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.

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.

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