Hyper-V R2 for VDI? Think again!

Share Button

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.

High Availibility

  • 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.

hyper-v1

Now the problems start because as I pointed out in the picture a VM is defined as three separate instances.

  1. Hyper-V manager shows it as a machine in the local Hyper-V management console the VM is running on
  2. The cluster shows the VM as a service on a cluster node
  3. 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.

Networking

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

Conclusion

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!

Share Button
  1. José RomeroJosé Romero02-23-2012

    Out of all the possible scenarios for 2008 R2 Hyper-V, VDI is one most suited in my opinion, specially for non persistent pools or pools with managed user identities.

    Today there are alternatives to manage VDI on Hyper-V without the complexity of clustering and VMM.

    • Barry SchifferBarry Schiffer02-24-2012

      Hi Jose, I agree with you that for shared stateless you don’t really need Clustering except for easier management (Live motion). However I think that in 99% of the VDI scenario’s use cases a customers wants clustering.

  2. Jasper KraakJasper Kraak02-23-2012

    Two Comments on the Networking:

    1. You say …”think Privisioning Services…” , if you let VMM do the provisioning there’s no need of a legacy adapter.
    2. The issues you encountered with Teaming could have been avoided by setting up MultiPath I/O properly.

    As you said, Networking is tough on Hyper-V R2, but doable; the point here is doing it RIGHT (you know what I mean :-))

  3. Jeff WoutersJeff Wouters02-22-2012

    You write that the VM is defined as three seperate instances… but that’s not entirely correct.
    On each of the three points you provide, you take a seperate management solution, each for their own scenario’s.
    1) Hyper-V Manager is to be used only for non-clustered environments.
    2) For clustered environments there is the Failover Cluster Manager but when you encounter something that’s not possible to configure through this console (or its PowerShell module) you may have to revert to the Hyper-V Manager on that host… but only for that reason.
    3) SCVMM is the management tooling intended for environments with large/multiple clusters, lots of stand-alone hosts, etc.

    So, the VM is not seen as three seperate instances hence SCVMM looks at the Failover Cluster Manager and the Hyper-V Manager (and some low-level access through the host itself)… so it would be two.

    The rest of the posts sounds solid… I (as a Hyper-V fan) recognize lots of your points and know that a lot of them will be solved in Hyper-V v3… so looking forward to your upcoming post about that 😀

    • Barry SchifferBarry Schiffer02-22-2012

      Thanks for your comment. Maybe it was better to say that “I see it as three instances”.

      What I did encounter was that a VM was running and shown in a local Hyper-V manager, it’s service was down on the fail-over cluster and it had duplicate entries within SCVMM.

      The Hyper-V v3 article will be up tomorrow and i promise it will have a more positive conclusion;).

Leave a Reply