I’ve recently setup a SQL cluster on a couple of VMs running on a 2012R2 Hyper-V cluster with a number of CSVs. As part of the performance testing I ran IOMeter to hammer the disks associated with the SQL cluster.

During the test I noticed that the Hyper-V host hosting the live SQL server had very little iSCSI traffic. I noted that the hyper-v host hosting the CSV containing the SQL disks was different to that hosting the SQL VM, this other host was showing high iSCSI traffic indicating that all iSCSI traffic was going via this host. In addition the cluster network between the two hosts being hammered.

Now I thought I knew how CSVs worked, i.e. all traffic between the hosts and the storage was direct regardless of the owner of the CSV in cluster failover manager. Unless a node looses it’s access to storage, then it will go into redirected mode and I’d expect to see all CSV access to be via the owner of the CSV as above.

Following lots of digging I now know why this is happening, and it’s down to the use of shared vhdx files required for the SQL cluster. When these are used all traffic will be redirected to via the coordinator node for that CSV over any of the cluster networks available.

This is only for shared vhdx files, non shared vhdx files will be accessed directly from the host to the storage regardless of CSV owner.

In my opinion this is not great, it means you need to consider the bandwidth and resilience of your cluster networks if you are using shared vhdx files within VMs, on the Hyper-V cluster.