Introduction into the VHD Set
I have talked about the VHD Set with a VHDS file and a AVHDX backing storage file in Windows Server 2016 in a previous blog post A first look at shared virtual disks in Windows Server 2016. One of the questions I saw pass by a couple of times is whether this is still a “normal VHDX” or a new type of virtual disk. Well the VHDS files is northing but a small file containing some metadata to coordinate disk actions amongst the guest cluster nodes accessing the shared virtual disk. The avhdx file associated with that VHDS file is an automatically managed dynamically expanding or fixed virtual disk. How do I know this? Well I tested it.
There is nothing that preventing you from copying or moving the avhdx file of a VHD Set that not in use. You can rename the extension from avhdx to vhdx. You can attach it to another VM or mount it in the host and get to the data. In essence this is a vhdx file. The “a” in avhdx stands for automatic. The meaning of this is that an vhdx is under control of the hypervisor and you’re not supposed to be manipulating it but let the hypervisor handle this for you. But as you can see for yourself if you try the above you can get to the data if that’s the only option left. Normally you should just leave it alone. It does however serve as proof that the VHD Set uses an standard virtuak disk (VHDX) file.
I’ll demonstrate this with an example below.
Fun with a backing storage file in a VHD Set
Shut down all the nodes of the guest cluster so that the VHD Set files are not in use. We then rename the virtual disk’s extension avhdx to vhdx.
You can then mount it on the host.
And after mounting the VHDX we can see the content of the virtual disk we put there when it was a CSV in that guest cluster.
We add some files while this vhdx is mounted on the host
Rename the virtual disk back to a avhdx extension.
We boot the nodes of the guest cluster and have a look at the data on the CSV. Bingo!
I’m NOT advocating you do this as a standard operation procedure. This is a demo to show you that the backing storage files are normal VHDX files that are managed by the hypervisor and as such get the avhdx extension (automatic vhdx) to indicate that you should not manipulate it under normal circumstances. But in a pinch, it a normal virtual disk so you can get to it with all options and tools at your disposal if needed.
Have you been able to setup Hyper-V replication on a VM with a VHDS? I’m getting the same message you get on 2012R2, i.e. you can not replicated VMs with shared disks.
Still working that one out. For my information are you using in guest cluster CSV or “standard” cluster storage?
CSVs, I wondering if it is down to the OS installed on the VM, need to test, but with a VM with No OS installed it’s failing.
Have you been able to get wbadmin to work with VHDs sets? I have not found any documentation on how to get this working. Nothing even stating it’s not supported.
wbadmin is the absolute minimum bare essentials if you really cannot have or even do anything else – it’s very limited. VHD Set with CSV is still not a primary citizen when it comes to backups (and replication) actually. VHD Set with now CSV clustered storage works with backup software that supports W2K16, suchs as Veeam, Altaro, DPM, …
I’ve set it up on my SQL 2017 cluster. But damn it’s buggy.
I got 2017-11 patch and the whole Cluster failed. Now I can’t add the drives to any VM as shared (VHDX or VHDS) I have to add them as single disk.
Since this is the only place I’ve found relevant information about VHDS I thought I’d give it a try here if anyone got anything like this?
Also see here:
https://community.spiceworks.com/topic/2089265-sql-cluster-broke-after-windows-update-using-vhds-vhd-sets?page=1#entry-7380607
If I try I get the following error:
[Window Title]
Settings
[Main Instruction]
Error applying Shared Drive changes
[Content]
Adding the device ‘Microsoft:Hyper-V:Virtual Hard Disk’ to ‘SQL1’ failed.
[Close]