Share via

How to avoid Redirected I/O in a Failover Cluster

SZ 5 Reputation points
2026-02-02T20:14:54.43+00:00

I have a 2 node Hyper-V cluster. Storage is a SAS Direct Attached with an HBA in both servers and a connection from each HBA to storage controller A and storage controller B. I have MPIO setup and recognized properly.

I have setup a CSV in failover manager and it is working. However, we've noticed that when Server A is the owner of a VM but Server B is the owner of the CSV, storage traffic for the VMs on Server A flow through the network of Server B.

My understanding is that this is expected behavior when/if one server has lost its connection to the storage. However I can change the owner of the CSV between Server A and Server B without issue so I know both servers have redundant and functional connections to the LUNs. It is also my understanding that, when healthy, the non-owner of the CSV still can have direct block level access to the storage (eg. without going through the owner node).

Any thoughts on how to avoid redirected i/o when the owner of the VM is not the owner of the storage? In my 2 node cluster, I can probably get away with this and keep all the VMs on one. But things change if I add a 3rd node to this. In that case, one or more server will be funneling all the storage traffic through the CSV owner node's NIC.

Windows for business | Windows Server | Storage high availability | Clustering and high availability
0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 21,275 Reputation points Independent Advisor
    2026-02-03T02:47:03.05+00:00

    Hi SZ,

    Thank you for the update of the root cause. However, I want to provide a crucial piece of technical context for your future infrastructure planning. The limitation you encountered is specific to Server 2012 R2. Starting with Windows Server 2016, Microsoft re-architected ReFS to fully support Direct I/O on CSVs. In fact, on Server 2016, 2019, and 2022, ReFS is the recommended file system for Hyper-V workloads because it enables accelerated VHDX operations (such as instant fixed disk creation and block cloning for checkpoints) which NTFS cannot do.

    Since you are running an environment where this limitation exists, sticking with NTFS is the correct stable choice to ensure you get the Direct I/O performance across your SAS fabric. Just be aware that when you eventually migrate this cluster to a newer OS version, you will not be bound by this restriction and should reconsider ReFS for its virtualization performance benefits.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments
  2. SZ 5 Reputation points
    2026-02-02T22:45:46.2366667+00:00

    Ended up being ReFS. It's not overly obvious but if you use ReFS, CSV's always function in Redirect I/O mode. Took me the better part of a day to figure this out and it ended up being just a few sentences in their CSV document that I needed to catch:

    https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-csvs

    0 comments
  3. VPHAN 21,275 Reputation points Independent Advisor
    2026-02-02T20:49:42.35+00:00

    Hi SZ,

    The fact that you can failover the CSV ownership proves that the physical path (MPIO/SAS) is valid, so the blockage is likely happening at the file system stack layer. The most common cause for a healthy node to fall back to Redirected I/O is the presence of an incompatible File System Filter Driver. When a third-party driver, such as antivirus, older backup agents, or replication software, attaches to the volume stack but does not explicitly flag itself as CSV-compatible, the Cluster service defensively forces the volume into Redirected Mode to prevent data corruption. This ensures the filter driver on the Coordinator node handles all traffic, effectively bypassing the local block access you are expecting.

    To diagnose this with precision, you need to query the cluster for the specific reason it has engaged redirection. Open PowerShell on one of the nodes and run Get-ClusterSharedVolume | Select-Object Name, FileSystemRedirectedIOReason. If the result returns IncompatibleFileSystemFilter, you have confirmed that a driver is the culprit. You can then use the fltmc instances command to list all filter drivers attached to the CSV volume and identify the non-Microsoft driver causing the fallback. If the reason is UserRequest, check if the volume was manually placed in redirected mode during previous maintenance.

    The suggestion to manually balance VM and CSV ownership is a band-aid that masks the problem rather than solving it. While it eliminates the network hop, it leaves you vulnerable; if that node fails and the workload moves, you immediately suffer the performance penalty of redirected I/O again. You should focus your efforts on identifying and updating the incompatible filter driver or software agent, which will allow the non-owner nodes to re-establish Direct I/O paths as designed.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments
  4. Q&A Assist
    2026-02-02T20:15:09.3033333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    To avoid redirected I/O in your Hyper-V failover cluster, you need to ensure that both nodes have direct access to the storage when they are healthy. Here are some strategies to consider:

    1. Ensure Proper MPIO Configuration: Since you already have MPIO set up, verify that it is correctly configured on both nodes. This includes ensuring that all paths to the storage are online and functioning properly. You can check this using the mpclaim -s -d command.
    2. Network Configuration: Make sure that the network configuration allows for optimal communication between the nodes and the storage. This includes checking for any network bottlenecks or misconfigurations that might cause traffic to be redirected unnecessarily.
    3. CSV Ownership Management: While you can manually change the ownership of the CSV, consider automating this process based on workload distribution. This can help ensure that the node hosting the VM is also the owner of the CSV, reducing the likelihood of redirected I/O.
    4. Cluster Network Prioritization: Maintain the default cluster-configured preferences for the networks. This ensures that cluster traffic, including CSV access, is prioritized correctly across your network.
    5. Monitor and Optimize Traffic: Use tools to monitor network traffic and identify any potential issues that could lead to redirected I/O. If you notice consistent patterns of redirection, investigate the underlying causes, such as hardware limitations or configuration issues.
    6. Consider Dedicated Networks: If you plan to expand your cluster, consider setting up dedicated networks for CSV traffic. This can help isolate and optimize the traffic flow, reducing the chances of bottlenecks and redirected I/O.

    By implementing these strategies, you can help ensure that your Hyper-V cluster operates efficiently and minimizes the occurrence of redirected I/O, especially as you scale to additional nodes.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.