Hyper-V versus VMware my take on a few topics

A colleague and I were "Discussing" the differences between Hyper-V and VMware Server Virtualization. I think we all know that both Microsoft and VMware have big marketing departments and both are working overtime to to promote their products.

This discussion started based on an blast email I sent about Hyper-V taking over at CH2M Hill to my company.
My Colleague found an article that he sent me that talks about how VMware feels that Microsoft is miss-informing information regarding the features of Hyper-V compared to Vsphere/ESX, http://blogs.vmware.com/virtualreality/2010/03/hyper-v-passes-microsofts-checkmarks-exam-isnt-that-always-the-case.html
I read the post and then responded with the below email to him around my experiences and information about the posts information: (Items in red below are taken from the above mentioned post)

Unlike vSphere, for example, Hyper-V R2 does not provide VM restart prioritization, which means that there is no easy way for admins to make sure that critical VMs are being restarted first. Incidentally, the lack of VM restart prioritization is one the reasons why Burton Group stated that Hyper-V R2 is not an enterprise production-ready solution
This is miss-information, You can control the priority of VMs restart by the delayed start setting. You would set a longer start time for VMs that are not a priority and set the start time for high priority VMs to zero. Read this about this debate, http://www.networkworld.com/news/2010/080910-vmware-microsoft-disaster-recovery.html?fsrc=netflash-rss

In addition because Hyper-V R2 lacks memory overcommit (a feature that is totally missing from Microsoft’s checklist), it can restart VMs only if the failover server has enough spare memory capacity to accommodate the VMs of the failed host.
This above statement about Memory overcommit is very comical as it is widely been reported on as a “Big Win for VMware” since Hyper-V entered the market. Before Hyper-V entered and even with Hyper-V in the field VMware has said that Memory overcommit is not recommended or supported for production environments. With Server 2008 R2 SP1 Microsoft is implementing Dynamic Memory, this is not memory overcommit but memory over-allocation. Microsoft has implemented a system whereas the host OS Hyper-V server communicates with the Guest OS VM to determine the memory needs of the guest and then allocates more memory to the guest. This is configured at the admin level by giving the guest a minimum (start up) memory and a maximum memory threshold; so I can configure a Guest to start with 512MB of memory and a maximum of 4GB of memory depending of need. This is fully supported in a production environment. What this enables is admins to configure guest to utilize physical host memory dynamically based on need, but still will not exceed the physical memory available to the host. Configuration also allows priority for this to be set per Guest.

This checkmark is funny to say the least. If you don’t know what the word “quick” means in Microsoft’s marketing jargon (and believe me I have heard illuminating translations of the term from Microsoft’s own employees), you’d think that Microsoft has a fast Storage VMotion (possibly faster than VMware’s). The reality is that even just talking about Storage VMotion in Hyper-V’s case doesn’t make sense, because Microsoft’s Quick Storage Migration, just like Quick Migration for VMs, cannot migrate VM virtual disks without downtime. VMware Storage VMotion, on the other hand, can migrate virtual disks without any application downtime.
Not sure what they mean, in the R2 version with Clustered Share Volumes, I have implemented many instances of Live Migrations that do not cause any downtime or interruption for a Guest/VM migration from one host to another.

As Microsoft TechNet shows, SCOM is a very complex product that consumes a considerable amount of servers and databases that – opposite to what Microsoft wants people to believe – are neither free nor included in the cost of SMSD licenses
it is true that SCOM is a paid product and requires additional server resources to implement but this is not required for Live Migrations. Plus implementing SCOM in an environment allows a company to not just monitor the virtual environment but all physical servers as well. Single pane of glass for all monitoring regardless of the server hardware solution.