Real Hyper-V vs. VMware comparison: What you actually get for free
- select the contributor at the end of the page -
Why I think vSphere is better and lower cost than Hyper-V
The vendor-based comparisons and case studies focus on the strengths of their own products, and downplay the competitor offering. Third-party publications may be biased because of marketing money or because of inherent loyalty as a result of familiarity with one vendor's offerings.
For example, a Microsoft shop may find it better to stick to the same vendor they've known and used for their OS, email and database solutions when considering virtualization or VDI options. Those shops would already have a good relationship with the vendor sales people and a degree of trust.
There are very few examples of a subjective comparison between the two based on a user's conclusion after proper testing. This article is my attempt to explain why I think vSphere is still better at a lower cost compared to Hyper-V.
Marketing can be annoying
At an early stage the Microsoft marketing spin made me dislike and distrust Hyper-V. When Microsoft couldn't support live migration of virtual machines, their marketing spin-doctors were saying that live migration is risky. We were told it was safer to pause the VM before migrating it because VMs should only be moved when necessary, and that VMware vMotion is a gimmick not recommended in production!!
Having used vMotion for years this sounded like an outrageous lie to me, and it was hurtful to see potential customers falling for it because they trusted the Microsoft brand.
Immediately after Hyper-V R2 started to support live migration, the marketing shifted to focus on this particular advancement and how VMware lost its major advantage against Microsoft. However, they neglected to mention that while Hyper-V moved only one VM at a time, vSphere was able to move many, perform vMotion faster, and can even be configured to use multiple network cards to do so.
The same thing happened with dynamic memory. vSphere has always had it, and it enabled VMware to achieve higher consolidation ratios (putting more VMs on physical hosts). At the time when Microsoft had nothing like this, they labeled it as bad practice and very risky. When they developed dynamic memory capabilities, suddenly it was the best thing since sliced bread. Yet again, the Hyper-V implementation of dynamic memory requires a painful and manual configuration per VM, while vSphere memory management just runs by default.
In addition, vSphere memory management is still years ahead of Hyper-V.
The ‘Hyper-V is free' myth
Indeed, you can add the Hyper-V role to a Windows Server for free and start creating VMs on it, but you can also install a ESXi server for free and use that to host your VMs. A small shop that cannot afford and/or does not need multiple physical hosts will get better value and reliability running the more efficient (smaller footprint) ESXi than the bigger, more complex Hyper-V.
I have installed such branch-in-a-box implementations before, and it's a method that continued to happily support SMBs for years without issues; it hosted both Windows and different flavors of Linux VMs. In one case, the host with 32 GB RAM was running VMs configured with more than 48 GB of RAM. I would not have done that with Hyper-V. I also worked with bigger shops that used the free ESXi installed on multiple hosts. In case of a host failure, they would simply move the disks containing the VMs to another host and add them to the host inventory.
What about Hyper-V Clusters without VMM, is that free?
I admit that a cluster of free Hyper-V servers should offer better high availability than separate ESXi hosts. However, I had a very catastrophic experience with it.
A cautionary tale
At a previous employer, the power of sales convinced management to install a free Hyper-V cluster of four nodes, and use it to host new VMs. Since I was the Systems Infrastructure Team Leader then, I was assigned this important project and I pulled it off. It took much more effort and time to implement than a comparable vSphere cluster, but I got it working and it passed all validation tests. I also set up a smaller two-node cluster for testing and dev.
When the time came to update Windows 2008 R2 to SP1 the unspeakable happened. The update went fine on the test cluster, but started to produce all sorts of storage errors on the production cluster. When opening any support case with Microsoft on clustering, you need to run the clustering validation tests. Running those tests resulted in corrupted volumes and lost production VMs, one of which had our SharePoint farm databases!
It turned out that this was a known bug in Windows 2008 R2 SP1 that does not manifest unless you have a cluster of three or more nodes. Apparently there is a hot fix for it that you need to request and download.
Three questions popped on my mind at that time:
- Did Microsoft not bother to test something as big as a service pack on a cluster that has three nodes or more?
- Do most Microsoft Hyper-V customers have less than three nodes?
- And why did Microsoft not reissue the service pack with the fix?
It originally took around two months to release the fix, and it took me two sleepless nights to fix the mess I had. Two days of downtime for our production SharePoint farm is not free. Actually it was very costly because important data used daily by the sales team was hosted on it.
Putting that one experience aside, I can assure you that daily and repetitive administrative tasks were taking longer to do with Hyper-V than with vSphere. For example, creating a new VM from a template was taking 15 to 20 minutes. In addition, it was nothing like cloning a VM on vSphere, where you go through the wizard in a couple of minutes and it will do what you want. To silence my concerns at the time, an MVP provided us with a PowerShell script he developed to automate cloning.
At that point it became obvious that to use the free Hyper-V, an investment needs to be made in automating and scripting the functionality that comes naturally with vSphere. Also, while vSphere felt like a complete product dedicated to virtualization, managing a Hyper-V cluster required visiting multiple interfaces and different parts of the OS to do simple tasks.
Soon after, management reached the conclusion that salesmen were leading them to try the free Hyper-V cluster. They ultimately decided to buy System Center Virtual Machine Manager to manage Hyper-V.
In Part II: What you really pay for, I will discuss why I think it is a mistake to choose VMM over vSphere considering all costs and benefits.
Want to improve the skills it takes to advance your IT career? Sign up for a 3-day free trial to access TrainSignal's entire training library.
