A very revealing case study just published by VMware describes how the cumbersome management of Hyper-V prompted a former customer to return to VMware. Dierbergs — a supermarket chain in the Midwest — began their virtualization journey in 2011 with VMware vSphere, but later succumbed to the temptation of seemingly lower cost Hyper-V and invested considerable effort in migrating over to the Microsoft hypervisor.
In the study, IT Infrastructure Manager Chris Lindloff highlights key frustrations they had with Windows Hyper-V:
Dierbergs experienced five major outages in a single year, taking down critical machines necessary for inventory and product ordering. “Even with the highest level of Microsoft support, we had difficulty resolving every outage,” says Lindloff. “Some of our outages lasted as long as 12 hours. One outage even corrupted a critical database server that we needed to restore from backup, resulting in significant data loss.
No surprise here — since Hyper-V is tightly dependent on Windows, Patch Tuesday applies not only to the applications running in the data center but also to the entire virtual infrastructure – double trouble! VMware vSphere takes an entirely new and different approach by using a very lightweight, purpose-built hypervisor as the foundation for a resilient software defined data center.
Technology leadership at Dierbergs made the critical decision to move back to VMware technology this year:
…while Hyper-V promised to be less expensive, that simply wasn’t true in practice. The total cost of ownership was far higher because of the need for additional management time and extensive support.
If your IT team is spending excessive cycles troubleshooting random connectivity issues or poring over disparate recommendations in an attempt to avoid patching disasters, consider the real-world experience of Dierbergs CIO Jim Shipley:
With the VMware solutions, we spend more of our day focusing on strategic initiatives, which in turn helps IT drive real value back into the business.
The hypervisor is a critical component of the data center, not a commodity as challengers would have you believe. Standardize on VMware vSphere so your technology pros can focus on the future, and the days of experimenting with alternatives will soon be in the past.
whoa! I’m a big fan of VMware, but Hyper-V isn’t so bad. Sounds like the problem here wasn’t due to Hyper-V, but a lack of training / knowledge on how to patch Hyper-V. This seems like bad patch management
And there’s free Hyper-V certification!
http://borntolearn.mslearn.net/btl/b/weblog/archive/2013/12/17/earn-your-microsoft-certified-specialist-server-virtualization-title-with-a-free-exam.aspx#fbid=5FHgP6yzeYd
It’s not always the technologies fault, remember the age old adage of people-process-technology?
The problem is not so much knowing *how* to patch Hyper-V — it’s keeping up with the flow of patches and hotfixes, assessing whether or not they are needed, and restoring broken clusters and network connectivity that result from some of the under-tested patches.
All of the links that Eric posted in this blog post come from very pro Microsoft/Hyper V sites, some or all of which are MVP’s in Hyper V. I have bought a few of their books as well and regularly use their sites when looking for Hyper V information.
Sadly Hyper V is not VMware, even with 2012 R2. IMHO it is a great solution in a non clustered environment, which relegates it to SMB shops. The irony is that Microsoft is pushing the SMB crowd into the cloud, their cloud, but it impacts their core Hyper V market as that is its only real success. I guess they get paid either way???
I don’t know why clustered hyperV servers are being built in full gui mode, run only clustered hyperV servers locked down, run nessus scans regularly against this and you’ll pretty much find that you won’t need to patch much at all. I’ll admit there are some real strange issues\oddities with w2k12r2 but nothing worth moving back to vmware.
“I’ll admit there are some real strange issues\oddities with w2k12r2” = DEV OR TEST ONLY.
Patching Hyper V/SCVMM is way more about fixing serious bugs vs security issues. A nessus scan just might make a CSV go off line 🙂
I think one of the weakest things about Hyper V in a clustered environment is upgrading to a new version. Hyper V does not support in cluster upgrades. You have to build a new cluster and migrate VM’s over. In 2012 R2 that is a little easier since you can migrate from a 2012 cluster. However you still need a new cluster, which is extra hardware. How many shops have that laying around? VMware supports in cluster upgrades. Upgrade vCenter, then roll the version upgrade through your hosts. No need for extra hardware.
“issues\oddities with w2k12r2″ = DEV OR TEST ONLY.” no not really, no problems as of yet. I’ll admit we are not pushing the configuration limits or using all features but we don’t have reasons as of yet to push these limits. Same is true for our vmware clusters, they just run simple work loads nothing fancy at all. We currently don’t use vmm and probably won’t for most of our hyper-v clusters.
My recent experience involves a UK customer whose infrastructure was in a post crash state. They had succumbed to the FUD and migrated 50% of their vSphere 4.1 environment to Hyper-V 2012 and Windows 2012 and hosted newly built mission critical VMs on this newly built infrastructure. I was not sure if they had followed MS best practices to built it but it seemed to be working okay albeit not as performant and as easy to manage as vSphere they reported.
A few months ago they experienced a severe crash within their shared storage system which affected LAN interconnect and SAN fabric overload. The outcome was the Hyper-V VMs all hung and LAN connectivity failed to them along with datastores in a somewhat crippling state. The vSphere infrastructure utilising the same LAN and storage had hosts that were not even patched and built to dissimilar build versions. HA and DRS kicked in restarted and moved some VMs around and only one VM had to be restarted. All Hyper-V VMs and hosts had to be restarted and what was worse never really recovered to an acceptable state and remained fragile.
I have since engaged with the customer, built new vCenter 5.5 and ESXi hosts and the customer is very relieved to have a very robust infrastructure and is now migrating back to VMware from
Hyper-V. Their comments were “what have we have done, so glad we still had licenses to move back from our big mistake”
Lesson learnt = you get what you pay for 🙂