2013
06.24

Windows Server 2012 Hyper-V allows you to create guest clusters of up to 64 nodes.  They need some kind of shared storage and that came in the form of:

  • SMB 3.0 file shares
  • iSCSI
  • Fibre Channel

There are a few problems with this:

  • It complicates host architecture. Take a look at my converged network/fabric designs for iSCSI.  Virtual Fibre Channel is amazing but there’s plenty of work: virtual SANs, lots of WWNs to zone, and SAN vendor MPIO to install in the guest OS.
  • It creates a tether between the VMs and the physical infrastructure that limits agility and flexibility
  • In the cloud, it makes self-service a near (if not total) impossibility
  • In a public cloud, the hoster is going to be unwilling to pierce the barrier between infrastructure and untrusted tenant

So in Windows Server 2012 R2 we get a new feature: Shared VHDX.  You attach a VHDX to a SCSI controller of your VMs, edit the Advanced settings of the VHDX, and enable sharing.  This creates a persistent reservation passthrough to the VHDX, and the VMs now see this VHDX as a shared SAS disk.  You can now build guest clusters with this shared VHDX as the cluster storage.

image

There are some requirements:

  • Obviously you have to be clustering the VMs to use the storage.
  • The hosts must be clustered.  This is to get a special filter driver (svhdxflt.sys).
  • The VHDX must be on shared storage, either CSV or SMB 3.0.

Yes, this eliminates running a guest cluster with Shared VHDX on Windows 8.1 Client Hyper-V.  But you can do it on a single WS2012 R2 machine by creating a single node host cluster.  Note that this is a completely unsupported scenario and should be for demo/evaluation labs only

Another couple of gotchas:

  • You cannot do host-level backups of the guest cluster.  This is the same as it always was.  You will have to install backup agents in the guest cluster nodes and back them up as if they were physical machines.
  • You cannot perform a hot-resize of the shared VHDX.  But you can hot-add more shared VHDX files to the clustered VMs.
  • You cannot Storage Live Migrate the shared VHDX file.  You can move the other VM files and perform normal Live Migration.

Even with the gotchas, that I expect MSFT will sort out quickly, this is a superb feature.  I would have loved Shared VHDX when I worked in the hosting business because it makes self-service and application HA a realistic possibility.  And I will absolutely eat it up in my labs Smile

EDIT1:

I had a question from Steve Evans (MVP, ASP.NET/IIS) about using Shared VHDX: Is Shared VHDX limited to a single cluster?  On the physical storage side, direct-attached CSV is limited to a single cluster.  However, SMB 3.0 file shares are on different physical infrastructure and can be permissioned for more than one host/cluster.  Therefore, in theory, a guest cluster could reside on more than one host cluster, with the Shared VHDX stored on a single SMB 3.0 file share (probably SOFS with all this HA flying about).  Would this be supported?  I checked with Jose Barreto: it’s a valid use case and should be supported.  So now you have a solution to quadruple HA your application:

  1. Use highly available virtual machines
  2. Use more than one host cluster to host those HA VMs
  3. Create guest clusters from the HA VMs
  4. Store the shared VHDX on SOFS/SMB 3.0 file shares

5 comments so far

Add Your Comment
  1. Hi Aidan
    Shared vhdx are great stuff!

    One question came to my mind – would it be possible to replicate those shared vhdx (and guest cluster virtual disks as well) with Hyper-V replica, e.g. in this way achieve DR?

    Best
    Goran

    • No.

      • Could you expand on no, why is not supported

        • Because it does not work. Simple as.

  2. I am seeing that with a shared VHDX file other benefits of non-shared VHDX files are also not working, such as SCSI retrim. My SAN is thin provisioned, but the shared VHDX file is taking up the entire file size (23TB) even though the Guest OS file cluster has deduplication enabled and the used size should be closer to 9.5TB. Following the guidance to shrink a regular VHDX file (Optimize-volume -retrim and then reboot) doesn’t work with a shared VHDX file (even when rebooting both nodes).

    Anyone else see anything similar?

Get Adobe Flash player