Fixing redirected access and mpio re‑binding on sofs clusters

Hello @Pate Adiya

If the CSV entered Redirected Access because one or more nodes lost direct storage connectivity, I wouldn't try to manually “re-bind” the CSV or MPIO claims first. Redirected I/O is a protection mechanism: when a node can't access the underlying CSV directly, it redirects I/O over the cluster network through a node that still has storage access.

First, determine exactly why each CSV is redirected:

Get-ClusterSharedVolumeState
Get-ClusterSharedVolume |
    Select-Object Name, State, OwnerNode
mpclaim -s -d

Get-ClusterSharedVolumeState is particularly useful because Windows reports the CSV state per node and provides the reason for redirected I/O. A VolumeRedirectedIOReason indicating NoDiskConnectivity, for example, points back to the SAN/MPIO path rather than CSV itself.

For the MPIO side, verify the affected LUN has all expected paths and that the DSM sees them correctly. Microsoft specifically recommends checking mpclaim -s -d when troubleshooting missing or failed storage paths. Also verify the HBA/iSCSI configuration, DSM version, drivers, firmware, zoning/masking, and SAN-side path state.

I would not remove and reclaim the LUN with mpclaim while the CSV is online just to force it back into Direct I/O. Fix the underlying path problem first. Once Windows and MPIO again present the LUN correctly to every cluster node, CSV should normally return to direct access automatically.

Also make sure the MPIO/DSM configuration is consistent across every cluster node. Microsoft recommends identical MPIO software, DSM, HBA drivers and HBA firmware across clustered servers using shared SAN storage.

After correcting the paths, validate with:

mpclaim -s -d
Get-ClusterSharedVolumeState
Get-ClusterSharedVolume |
    Format-Table Name,State,OwnerNode
Test-Cluster

If the CSV remains redirected even though mpclaim shows all expected paths healthy, check the Failover Clustering and storage event logs for 129, 153, 5120, 5142, 1069 or 1205 events and check SAN/controller logs around the original path failure. At that point, I'd involve the SAN/DSM vendor or Microsoft Support rather than manually manipulating the disk claims on a production cluster.

One important distinction: if by “S2D cluster” you mean Storage Spaces Direct, MPIO shouldn't be used for the S2D member drives. Microsoft explicitly states that multipath I/O is unsupported when S2D drives are accessible through multiple paths. If these are separate SAN-backed CSVs coexisting with S2D on Windows Server 2022+, that's a different and supported architecture; the SAN LUNs remain separate from the S2D pool.

Sharing these references with you:

Cluster Shared Volumes overview · Failover clustering hardware and storage requirements · Troubleshoot Hyper-V and Failover Cluster storage issues · S2D hardware requirements

Please "Accept the Answer" if this information helped you. This will help us and others in the community.