Strategic Implementation Differences Between Hyper-V and vSphere
December 19th, 2009 | 
Author: Forget the feature matrix with all the check marks. Forget the price comparison and the price per virtual machine or cost per application. For the sake of consideration, assume an “apples to apples” scenario and focus on VMware and Microsoft virtualization solutions, vSphere Enterprise (or Plus) and Server 2008 R2 with the Hyper-V, as production implementation projects. Put yourself in the shoes of someone responsible for implementing both virtual infrastructures and following best practices. Forget bias. Forget allegiance. Build the best virtual infrastructure design based on the prerequisites and requirements of each solution. Build it with the best interest of the company who will administer and support it going forward.
There is a lot to consider in the first paragraph, and as any consultant would say, the final decision depends on what other objectives the solution will need to satisfy besides just serving as server infrastructure. Again, for the sake of consideration, I’m going to zoom in on the server infrastructure and leave the “other” out of the implementation.
Again, for the sake of consideration, can the difference between choosing to implement production virtual infrastructure with VMware or Microsoft be simplified to a aligning with either companies strategic vision? I’ll attempt to make that case in this post.
For the sake of being open and honest before I continue, I’ll state up front that I personally have yet to implement a production Hyper-V environment, but as a consulting engineer working for a large Microsoft partner, I’ve sat in certification training, experimented a little in the home lab, and have been looking very closely at the implementation services needed to deploy Hyper-V for customers recently.
This post holds my thoughts on some major implementation differences as I understand them today. Please point out where I have missed the mark or help me consider other factors that I may have missed.
Microsoft virtualization is a part of Windows
Implementing Hyper-V Makes the most sense after you already have Active Directory (AD) with System Center Operations Manager (SCOM) already in place. Sure, Hyper-V Server 2008 can be installed bare metal as a stand alone hypervisor or it’s possible to build VI with Server 2008 core before AD, but are those scenarios really feasible for production?
Hyper-V with HA (Quick Migration), Live Migration, and all of the other advanced features essentially depends on Fail Over Clustering. Fail Over Clustering depends on Active Directory. Therefore, it makes the most sense to establish physical AD infrastructure and join Hyper-V hosts to the Forest or Domain. Sure, most companies will already have a healthy AD already in place.
Should System Center Operations Manager and Virtual Machine Manager be physical as well? They don’t have to, but that decision, in my opinion, ultimately comes down to a comfort level about running the monitoring and management servers inside the environment they are monitoring and managing. Logistically speaking, the SCOM pieces may be the first VMs created on the first several Hyper-V hosts, however. Since the added value of SCOM is administration of physical hosts as well, does it make more sense to keep SCOM physical too?
Think about my scenario as a consultant. Given a week or so to perform the implementation and server consolidation as a turn key project, I can build stand alone Hyper-V servers and manage them with the Hyper-V Manager easily enough, but I will quickly need Fail Over Clustering. SCVMM is arguably needed shortly after.
These are some implementation reasons that align with the idea that Microsoft has built Hyper-V as an extension of a Windows infrastructure that already exists. Hyper-V seems to favor scenarios where parts of the environment will be consolidated. If you really think about it, of course Microsoft would do it this way.
VMware wants to virtualize 100% of your data center
Active Directory makes life easier in VMware vSphere environments too, but implementing most of the desirable vSphere features is not dependent on it. DNS is needed, but not necessarily Microsoft DNS.
An ESX Cluster is not a traditional, quorum based application cluster but instead a pool of hardware resources joined together by the vCenter Management Server and it’s agents deployed on each ESX host. Microsoft Clustering is not needed and it’s dependencies can be avoided.
Most of the VMware implementations I have been involved with over the last 4 years could have been viewed as complete data center migrations. I’ve suggested that migrating to VMware VI should be treated by the IT Team the same as a physical data center move based on that fact. Therefore, customers usually P2V the Microsoft AD infrastructure entirely to the VI. More times than not there is a tough decision about whether to leave at least one physical DC in the environment.
Final Thoughts / Questions
To summarize the last 2 sections I pose some implementation centered thoughts / questions to VMETC.com readers:
- Is it an important point to understand that a VMware vSphere environment can completely host Windows AD infrastructure as guests eliminating the need for any physical servers other than the vSphere infrastructure?
- Does it matter that Microsoft Hyper-V environments need an established Windows environment? Remember I am talking about production implementation using best practices for your company / my customers. I know Hyper-V can be configured in a workgroup without a DC, but is that really an production implementation option considering feature needs like Live Migration and HA?
- Do you view a layer of separation between Active Directory and the hypervisor as an added benefit? What happens if you corrupt the AD database in VMware versus Hyper-V environments?
Let me know your thoughts!
Related Posts
Posted in feature comparison, hyper-v, vSphere, vmetc.com | 
Tags: hyper-v, microsoft, microsoft hyper-v, vmware, vSphere
-
Tom
-
Won
-
rbrambley
-
rbrambley
