Missing suppoort for restore to SOFS

[jzilak]

Hello,

it would be nice to add full SOFS Shares support to VBR. Currently there is missing support to restore any VM to different host stored on SOFS or restore any particular VM file to SOFS Share directly.

Regards
josef

[foggy]

Hi Josef, could you please clarify your request, since you should be able to restore directly to the share by specifying the destination UNC path explicitly in the restore wizard?

[nmdange]

You can restore using the local path of one of the SOFS nodes directly, i.e. C:\ClusterStorage\CSVVolume\restoredir

[jzilak]

I'm aware about this bad option, but this workaround work enough only for very few shares on storage system with small attached capacity around ~10 TB. For systems with tens or more shares across +100 TB , it is very difficult find right volume hosted right share, because share names are at different layer than mapped CSV volume. Second, C:\ClusteStorage patch is not aware about node locality, so restore to that path can cause hi backed redirect traffic to optimal node that hosts share itself (for asymmetric storage technology like Shared Storage Spaces). Last lost benefit is write persistence during fail over. Local ClusterStorage path do not offer persistent handles, so Share or CSV fail over cause restore job fail.

There is two changes what will be help:
1. expose Clustered SOFS path to restore dialog for example \\SOFSClusteredRole\ShareName
2. add possibility restore whole VM to alternate path on Hyper-V cluster that use SOFS as remote storage. for example restore VM to Hyper-VCluster with file stored on \\SOFSShareName

[nmdange]

If you have left your CSV volumes at the default names of "Volume1/2/3" I would highly, highly recommend renaming the folder inside of C:\ClusterStorage so you know what's what. I always rename the CSV volume path to match the name of the file share. I also set the volume label when the drive is formatted to the same name. For SAN storage the volume is also labeled the same within the SAN itself. For Storage Spaces, the Storage Pool and virtual disk names are used to name volume and share. I also rename the disks within Failover Cluster manager. You should never have to guess which volume is which!

I can understand about redirected I/O, it's never been an issue for me though even on storage spaces.

[jzilak]

Rename links in CSV namespace is valid only for manually managed systems. For SOFS managed by SCVMM, there is no way how to rename CSV links. Also SOFS shares are placed inside volumes and finding any particular share on system with more than 10+ shares is extremely boring.

IO redirection is an issue especially for random IO pattern. based on our tests, latency is increased more than two times, compared non-redirected IOs.

[nmdange]

I use SCVMM to manage the file shares, but I do create the CSV volumes ahead of time. VMM does not have sufficient advanced options to properly create volumes. For example, for large CSV volumes, you always want to use NTFS 64k clusters with Large File Record Segments. Also when creating a storage spaces virtual disk, you can't control key parameters like column count that you need to ensure autorebuild works correctly. So I always create the volumes and format them on the SOFS cluster itself and then use VMM to create the file share on the volume.

I understand your original point but I have almost 200TB of space spread across several SOFS clusters and I've never had a problem finding the path for a specific file share because I always ensure things are properly labeled. There should also be one file share per volume with the volume name matching the file share name. So if I see in VMM a VM is hosted on \\sofs\StorageArray1_Disk2, I know which SAN disk that is and the CSV path is C:\ClusterStorage\StorageArray1_Disk2\Shares\StorageArray1_Disk2\VMName.

I know it's not easy to fix after the fact but you are going to keep running into little things like this that slow you down when things aren't clearly labeled.

[jzilak]

I think you answer yourself You don't use VMM for SOFS management, so it can work well for you. But in implementation, where VMM is used for full SOFS management, there is simple nothing like Volume link labeling. 200TB RAW storage is something like 10 Volumes, try imagine systems with 1000+ TB with 100+ volumes.

Add NTFS - VMM 2016 + ReFS solve your legacy FS optimizations
Add VD - Properly setup Storage Pool defaults can solve your per VD customization.