Hi Hyper-V Friends,
The following important fact will probably only be known to very few admins today.
In all previously published and also the current Hyper-V versions, all write operations that are processed by the Hyper-V storage stack are always passed on to the underlying storage subsystem as WRITE-THROUGH.

The bottom line is that, every Hyper-V forces the underlying storage subsystem to completely bypass the write cache built into the RAID controller or the SAN. Even then, if the Wirite Cache is activated in the controller policy and is also requested via the application. This active bypassing of the write cache leads in most cases to very massive performance losses when writing!

Incidentally, this behavior is documented by Microsoft, but this information is very well hidden and not easy to decipher at first glance.

https://docs.microsoft.com/en-us/troubleshoot/windows-server/virtualization/hyper-v-storage-caching-layers-data-consistency-requirements

“Host filesystem cache. The Hyper-V storage stack also uses unbufferred writes to make sure that the writes from the guest bypass the underlying host filesystem stack.”

I understand that in some systems / scenarios, especially those where critical data is involved and the write cache of the storage is for example not buffered by a battery, it is wiser to work with WRITE-THROUGH. Therefore I would respect, if the Hyperv works per standard with "WRITE-THROUGH", but I as the admin would also have the possibility to change this behavior to "WRITE-BACK" or "ORIGINAL IO", so thus my expensive and batterybuffered SAN cache, can be used sensibly for writing again.

Best Regards from Germany

Alex

To provide the Ultimate Disaster Recovery solution across separate clusters for Active/Active scenarios (same HW) or Active Passive scenarios (different HW), Providing a One to Many placement via Synchronous/Asynchronous Replication, providing RPO/RTO of choice, and to automatically Orchestrate failover of VM's to destination of choice with the RTO of choice, to patch and complete lifecycle management on each cluster without impact to overall service.

Why is Cluster to Cluster DR solution important, A Stretch Cluster can still suffer issues at the Hyper-V level and impact the whole cluster, the same for life cycle management and patching, requires the same hardware configuration and be symmetrical and unlikely to support one to many replication configurations.

To increase interoperability with Linux and to give more options for administrators Microsoft should include a fully-featured BTRFS implementation in Windows Server. This should include all the RAID modes for when creating a BTRFS RAID, Single, Raid1, Raid10, Raid5, and Raid6 (yes I know BTRFS is broken with Raid5 and Raid6, perhaps Microsoft could work with the resolve the issue). We should be able to also format any disk partition with a BTRFS volume. Snapshot creation should integrate with VSS and snapshots should appear in the "Previous versions" tab. Bitlocker should be able to be used with BTRFS as well. Once a Windows Server implementation is ready, it should also eventually find its way into Windows 10 Pro as well.

Have configured standalone SQL servers with AlwaysOn Availability groups configured for HA. Now when adding two local disks to each server the disks are linked to the clustered storage subsystem not the local one which means I am unable to create a storage pool in Server manager as it states that a minimum if 3 are required to create a cluster storage pool. However I only want to create a local one - not a clustered pool.

Can you please provide a way to either disable the clustered storage subsystem (not need in this config as only a standalone SQL server is installed and I only want to use local disks) or, provide a way to change the link from the clustered storage subsystem to the local storage subsystem