Issues with continued use of Shared VHDx

Hi all,

I have been struggling to get Shared VHDx to work properly for the last week or so.  I have a two 2012 R2 file server VMs clustered sitting on a Windows Server 2012 R2 Hyper-V cluster, I would like to use Shared VHDx for the Quorum Disk Witness and for the File server cluster storage.

Initially when I first create, share and add the VHDx to the two file servers it works without an issue, the file server cluster role will live migrate and storage stays accessible.  However after a period of time e.g. overnight if either of the servers are shutdown/restarted they will not restart.  The error I receive is:

'FS1B' failed to add device 'Virtual Hard Disk'.

Failed to open attachment
'Path to disk\Quorum.vhdx'. Error: 'The request is not supported'.

'FS1B': Cannot get information for attachment 'Path to disk\Quorum.vhdx'.

Failed to open attachment 'Path to disk\Quorum.vhdx'. Error: 'The request is not supported.'.

I have searched around online and came across a couple of people with a similar issue, one fixed it with adjusting his Network Binding (this did not help me).  If I turn off the sharing on the VHDx the server it is attached to will boot fine.

I have also made sure the networking and storage access to the Hyper-V hosts are identical and that all four servers are up to date patching wise.

I don't think I'm missing anything but it really doesn't want to work and driving me a little nuts.

Thanks!

February 2nd, 2015 7:03pm

On thing that is not clear that I must assume: your shared VHDX is on a third shared storage source of some type.  Such as an SMB3 share, Cluster shared volume, etc. that both Hyper-V Servers can access (and in turn both VMs can as well).

The shared VHDX must be on some volume that clustering can manage / is managing - in order for clustering to handle the file locking properly.

https://technet.microsoft.com/en-us/library/dn265980.aspx

Free Windows Admin Tool Kit Click here and download it now
February 2nd, 2015 7:17pm

I realised I hadn't been clear about that on my way into work this morning.  The shared VHDx are sitting on an HP P4500 G2 iSCSI CSV.

Thanks

February 3rd, 2015 11:22am

Hi Planescape,

>>However after a period of time e.g. overnight if either of the servers are shutdown/restarted they will not restart

"either of the servers" means hyper-v hosts ?

Please check if there is any error message in event log .

Please ensure two file server VMs are all checked "Enable virtual hard disk sharing" checkbox .

Best Regards,

Elton JI

Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2015 12:48pm

Hi Elton,

"Either of the servers" means the file cluster VMs and they both had the "Enable virtual hard disk sharing" checkbox ticked under the Advanced Features section for the VHDx.

I can't see anything relating to it in the events logs currently, I have checked the Application, System and Hyper-V Shared VHDx.

There are some previous entries in the 'Hyper-V Shared VHDx' log that relate to earlier instances of the problem.  I hope that makes sense.

I have tried removing the VHDx and reattaching them but that won't work either.

February 3rd, 2015 4:22pm

If I understand what is being done here correctly a VHDX file resident on a file share is being direct attached to the two Hyper-V hosts?

What you are experiencing may be a timing problem. The iSCSI connection is not initialized before the cluster components are. You could set your Cluster and virtualization services to Automatic (Delayed) to give the disk subsystem time to sync itself up with your target.

Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2015 6:08pm

It's possible I'm not being very clear as I think you have misunderstood it.  The Hyper-V hosts are fine and their access to the iSCSI CSV is functional.  The problem is the VMs throw up this error when I add a Shared VHDx that is stored on the Hyper-V Hosts CSV. 

  • Hyper-V Host cluster 'HVCLLAB1' with an iSCSI CSV e.g. C:\ClusterStorage\Volume1.  This is all fine.
  • Two virtual file servers in a cluster 'FSCL1'
  • The quorum and storage disks for the virtual file server cluster are Shared VHDx that are stored in the 'HVCLLAB1' CSV.  They are added to the virtual file servers through Failover Cluster Manager running on one of the Hyper-V Hosts.

I hope that makes sense.

February 3rd, 2015 6:45pm

It's possible I'm not being very clear as I think you have misunderstood it.  The Hyper-V hosts are fine and their access to the iSCSI CSV is functional.  The problem is the VMs throw up this error when I add a Shared VHDx that is stored on the Hyper-V Hosts CSV. 

  • Hyper-V Host cluster 'HVCLLAB1' with an iSCSI CSV e.g. C:\ClusterStorage\Volume1.  This is all fine.
  • Two virtual file servers in a cluster 'FSCL1'
  • The quorum and storage disks for the virtual file server cluster are Shared VHDx that are stored in the 'HVCLLAB1' CSV.  They are added to the virtual file servers through Failover Cluster Manager running on one of the Hyper-V Hosts.

I hope that makes sense.

I think I got it.

You are nesting the VHDX files _within_ the cluster guests?

If that is the case then the cluster would not be online until after the guests finish their own boot and initialization processes.

Chicken and the egg.

Essential cluster resources like the witness disk should be direct attached to an iSCSI LUN not nested within the guest workloads.

Guest clusters are possible but the focus would be on the workloads they would be running internal to themselves.

I hope I have things correct this time around. Essentially, putting your cluster witness disk within the guest workloads is not a good practice.

Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2015 6:53pm

Just so I'm being clear the Disk Witness I'm referring to is for the secondary file server cluster, not the Hyper-V cluster.

I'm not mounting the Disk Witness for the Hyper-V cluster within the virtual guest File Server cluster that runs on top of the Hyper-V Cluster.

I am essentially trying to do 'scenario one' of this - https://technet.microsoft.com/en-gb/library/dn265980.aspx

February 3rd, 2015 6:59pm

My apologies, need a bit more caffeine in the grey matter. ;)

In Failover Cluster Manager you can tweak the logging settings to include all aspects of cluster communications and management. Within the logs, once tweaked, is there a clearer set of errors that may indicate where the process is stalling?

What device is hosting the VHDX and what are the permission sets for it to deliver the shared VHDX?

Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2015 7:07pm

Hi Planescape,

Could you please tell us the path of the Host's CSV , also the path that the VMs' "shared VHDX" files residing in ?

Best Regards,

Elton Ji

February 4th, 2015 10:42am

In Failover Cluster Manager you can tweak the logging settings to include all aspects of cluster communications and management. Within the logs, once tweaked, is there a clearer set of errors that may indicate where the process is stalling?

What device is hosting the VHDX and what are the permission sets for it to deliver the shared

Free Windows Admin Tool Kit Click here and download it now
February 4th, 2015 2:40pm

Hi Planescape,

>>However after a period of time e.g. overnight if either of the servers are shutdown/restarted they will not restart.

>>If I turn off the sharing on the VHDx the server it is attached to will boot fine.

Let's turn back to the original post .

The two VMs are high-available virtual machines , right ?

After you shutdown them all , the error will arise when you start either of them ?

Best Regards,

Elton Ji

February 8th, 2015 6:07am

Hi Elton,

That is correct they are both Highly Available VMs and the error arises on either VM if you try to start it.

Thanks

Free Windows Admin Tool Kit Click here and download it now
February 9th, 2015 5:58am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics