The reason for this article is to explain why I don’t like Hyper-V R2 in a production scenario especially for VDI. In a next article I will go into detail about why I think Hyper-V v3 is likely and hopefully going to proof me wrong!
The people I work with closely know I tend to hate Hyper-V R2 for production (VDI) scenario’s and I will start with explaining why. The short version is that you need to many components to manage the hypervisor which leads to technical issues.
- To create a High Available setup we start with creating a Fail-Over cluster.
- Standard cluster storage is by default not able to be used by multiple cluster members at once so Microsoft came up with a solution called Cluster Shared Volumes (CSV) which has his own downsides but most important we can share a CSV across multiples hosts at the same time.
- To manage the cluster nodes properly we need an extra management solution and this is where the next component comes in which is called System Center Virtual Machine Manager (SCVMM). SCVMM gives us a great and easy to use interface for our platform. Next to SCVMM we need SCOM to bring us DRS like functionality.
The picture below shows a platform based on the components I just described.
Now the problems start because as I pointed out in the picture a VM is defined as three separate instances.
- Hyper-V manager shows it as a machine in the local Hyper-V management console the VM is running on
- The cluster shows the VM as a service on a cluster node
- SCVMM shows the VM and Server as separate agents.
This is a problem because eventually SCVMM will start to disagree with the other components about the status and location of a VM. This results in weird Power On/Off actions and even duplicate items in SCVMM. This gets worse in the event a node fails and all the VM’s are moved across other nodes. Because it’s the Fail-Over cluster that performs all the actions SCVMM is not properly informed and has a complete own vision of the state of a VM.
Now imagine a VDI scenario with thousands of XenDesktop VM’s. XenDesktop is going to mingle in the “discussions” SCVMM has with the cluster because it wants to know everything about a VM. When XenDesktop thinks a VM is unregistered it will try to shutdown and restart the VM which will cause more actions and eventually also the Fail-Over cluster stops responding.
This all might sound like a doom scenario but I have seen this happening within an environment with only 200 vm’s which was properly configured.
The networking in Hyper-V R2 delivers great performance and with SCVMM it’s also pretty easy to configure. I admit it’s not VMware but it’s doable.
There are a couple of things however that are a bit crappy to say the least
- PXE boot requires a legacy network adapter – Think Provisioning Services……
- Network teaming needs network vendor based teaming software – Which isn’t even supported by Microsoft
Remember that it’s my personal opinion! Don’t use Hyper-V R2 for big and dynamic, especially VDI, production scenario’s. Hyper-V is a great hypervisor with a huge potential but the management architecture just plain sucks!
I know this will probably offend some people and feel free to comment. Please also read my post about Hyper-V v3 because I really think that this will make a huge difference!