Hyper-V Shared Virtual Disks Beta

Hyper-V Shared Virtual Disks Beta

We’ve been busy here at Tintri HQ. One of the things that has taken up a chunk of my time is taking a look at some functionality that is currently in beta. Specifically Shared Virtual Disks for Hyper-V.

Overview

Shared Virtual Disks allow you to have multiple virtual machines that have a common virtual disk (often multiple) that each of the VMs can communicate. The primary use case for this is for highly available clustered applications that require shared storage and quorum. Much in the same way that a Tintri VMstore has two controllers for redundancy and common storage between the two.

These clustered VMs are configured as active-passive sets where the active VM is the one that currently has the ability to do I/O to the storage.

More Information

Shared Virtual Disk support over SMB sounds pretty simple, but there’s a lot to it. It involves taking SCSI commands, such as those used to manage SCSI reservations on shared storage, and tunnel them within SMB commands. If you’re really interested in how this works, you can find out more in the MS-RSVD specification.

A big shout out to our friends at Microsoft who have been working with us for quite some time on this and helping to make sure that any ambiguities in the spec were cleared up.

Deployment

Deployment of clustered VMs is a little more involved than a standalone VM. The way we’ve been doing it is to take a freshly sysprepped Windows 2012r2 VHDX file, create two VMs from it and create and add the shared disks to it. From there, I can set them up as a Microsoft Failover Cluster and install clustered SQL.

We’ll use standard Hyper-V PowerShell cmdlets to demonstrate the process.

First, creation of the two VMs. Note that they have no disks attached yet.

$mastername = "SQL-1"
$slavename = "SQL-2"
$smbpath = "\\vmstore01-data.vmlevel.com\VMs"
$masterpath = "$smbpath\$mastername"
$slavepath = "$smbpath\$slavename"
$master = New-VM -Name $mastername -Path $masterpath -MemoryStartupBytes 8GB -Generation 2 -NoVHD
$slave = New-VM -Name $slavename -Path $slavepath -MemoryStartupBytes 8GB -Generation 2 -NoVHD

Next, we copy the operating system vDisk to each VM’s folder and add it to the VM.

$vmtemplate = "\\vmstore01-data.vmlevel.com\Templates\Windows Core 2012r2.vhdx"
copy $vmtemplate "$masterpath\$mastername.vhdx"
Add-VMHardDiskDrive -VM $master -Path "$masterpath\$mastername.vhdx" 
copy $vmtemplate "$slavepath\$slavename.vhdx"
Add-VMHardDiskDrive -VM $slave -Path "$slavepath\$slavename.vhdx"

You’ll notice that because the template is on the same storage appliance as the VMs are being deployed to, that the copy of the vDisk is nearly instant. This is due to local copy offload or ODX, which is something that we’ve covered before. If the template was on one VMstore and being deployed to another VMstore, distributed copy offload would kick in making the copy far quicker than usual.

At this point, our VMs are pretty-much standard. They have a single disk from a common golden image.

Next, we need to create the shared disks and attach those. In this case, we intend to have two shared disks for my SQL 2014 instance — one for the data and one for logs. Here’s how:

New-VHD -Path "$masterpath\$mastername-data.vhdx" -Fixed -SizeBytes 100GB
New-VHD -Path "$masterpath\$mastername-logs.vhdx" -Fixed -SizeBytes 25GB

Add-VMHardDiskDrive -VM $master -Path "$masterpath\$mastername-data.vhdx" -SupportPersistentReservations
Add-VMHardDiskDrive -VM $master -Path "$masterpath\$mastername-logs.vhdx" -SupportPersistentReservations

Add-VMHardDiskDrive -VM $slave -Path "$masterpath\$mastername-data.vhdx" -SupportPersistentReservations
Add-VMHardDiskDrive -VM $slave -Path "$masterpath\$mastername-logs.vhdx" -SupportPersistentReservations

Things to note here:

  1. The -SupportPersistentReservations option. This is where the magic happens and allows these two VMs to share the same vDisk
  2. We’ve placed the two share vDisks under the same directory as the master and simply pointed the slave to it, but this is arbitrary. These shared disks could be in their own directory. It is important to keep them all somewhat local to each other though.

At this point, we have two virtual machines that both have common, shared storage over SMB3.

This is how it looks in Hyper-V Manager once deployed:

RSVD-disk

In a follow-up article, we’ll look at provisioning this shared storage and setting up the Failover Cluster.

Limitations

As mentioned, this functionality is still in beta and not yet generally available. When the initial support is released, it will come with some temporary limitations. The focus has been put on data integrity above everything else, so to limit the development and test scope and allow more resources to prove out the data integrity side of things, the use case for Shared Virtual Disks over SMB is currently limited to:

  • Windows 2012r2 Hosts
  • Windows 2012r2 Guests
  • SQL 2014 as a clustered guest application
  • Shared disks must be fixed VHDX
  • Snapshots and replication are currently not supported

More specific detail around these use cases will accompany the release, but we’re always interested to hear your thoughts and requirements around additional use cases and functionality.

[High Availability image by flattop341 and used unmodified under CC2.0]