Windows – mount a VHDX read-only while also sharing it read-write over iSCSI

iscsiwindowswindows-server-2016

I have two servers, both running Windows Server 2016 Standard, both are VMs on top of a Windows Server 2016 Standard Host, using Hyper-V.

One server runs a service that needs to store data on a local file system, that is, something with a drive letter. No UNC paths, no SMB, no Authentication.

The other server is a file server.

What I would like to do is for the application server to store the application data on the file server. I can do this via iSCSI, which creates a VHDX on the File Server. This works fine, the application successfully stores its data on this hard drive.

However, I would like to make backups of the content of the VHDX, and ideally have that done on the file server. For that, I would need to mount the VHDX – but I can't do that, because it "is in use by another process". That's a bummer.

Is there a (supported) way to keep a VHDX mounted read-only on the File Server while sharing out over iSCSI? I am not worried about the application server trying to format or create partitions or something. I'm flexible on the file system (NTFS, ReFS or even ExFAT).

I wondered if I should just move the VHDX to the physical host machine and then attach it to both VMs as Shared Hard Drives, but it seems that this is meant for failover clustering.

Maybe iSCSI and VHDX isn't the right approach here, are there other supported ways to have one drive letter on Server A actually write data to a location on Server B in a way that Server B can access the files, while still being able to use Volume Shadow Copies (VSS) for backup purposes? (and yes, installing a backup agent on Server A is a possibility, but I want to keep things as simple as possible – I realize iSCSI might be overkill as I'm sharing an entire block device out, when really, I just want a shared folder).

Best Answer

Making long story short: you can't do that. Even in a single writer mode nobody is going to update your sibling reader about metadata changes on a block volume: unmount/mount sequence would be needed to update second "shadow" $MFT.