Windows Server 2012 R2 Hyper-V – Guest Clustering With Shared VHDX

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.


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


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
Please follow and like us:

9 Comments on Windows Server 2012 R2 Hyper-V – Guest Clustering With Shared VHDX

  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?


  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?

  3. Not being able to dynamically expand a shared VHDX is not an insignificant limitation. Hot adding a drive is useful, but if you are running out of space that means spanning a volume (is that even possible, since you need to use basic disks), or trying to shuffle data around. The reason why we have failover clusters is to avoid downtime when doing maintenance.

  4. I’m testing SVHDX in my environment and I can’t get it working. We have setup failover cluster and CSV backed by SAN over FC, I have put SVHDX on CSV and attached that disk to two VMs. Now I have inconsistency on the disk as I save few files on the VM1 they are not visible on the VM2 and CHKDSK is reporting errors. I think that I’m missing something here, did I get SVHDX point all wrong or ?

Leave a comment

Your email address will not be published.