s mpclaim -r -i -a required for MPIO on an existing 2-node Windows Server 2022 Hyper-V Failover Cluster? We have an existing production Windows Server 2022 Hyper-VFailover Cluster with 2configured nodes, connected to HitachiOPEN-V sharedSANstorage via fc

mpclaim -r -i -a is not universally mandatory; first select the Hitachi-supported DSM and exact OPEN‑V hardware IDs, then claim only those devices and reboot one drained node at a time.

DSM and claiming decision

The MPIO feature alone does not make existing LUNs multipathed. The DSM must claim the storage devices, which explains why mpclaim -s -d currently reports no MPIO disks.

Choose one supported model for Windows Server 2022:

• Hitachi vendor DSM: install and configure the exact Hitachi-supported package and settings. Do not also claim the same LUNs with MSDSM.
• Microsoft DSM (MSDSM): obtain Hitachi confirmation that MSDSM supports this OPEN‑V presentation, including the required load-balancing policy and failover settings. Identify the devices with:

Get-MPIOAvailableHW -BusType FibreChannel
Get-MPIOSetting
Get-MSDSMAutomaticClaimSettings

Get-MPIOAvailableHW returns devices MSDSM can manage and provides the vendor/product IDs needed for an explicit hardware-ID claim.^1^

For an MSDSM deployment, add only the vendor/product ID confirmed by Hitachi:

New-MSDSMSupportedHW -VendorId "<VendorID>" -ProductId "<ProductID>"
Update-MPIOClaimedHW

New-MSDSMSupportedHW adds the ID to the MSDSM list, and Update-MPIOClaimedHW applies claiming; an unsuccessful online claim means a restart is required.^2^^3^

Do not start with New-MSDSMSupportedHW -AllApplicable or mpclaim -r -i -a on this production host. “All applicable” includes applicable FC, iSCSI, and SAS devices, rather than only the intended Hitachi LUNs.^2^ Microsoft documents mpclaim -r -i -a as a broad troubleshooting/recovery action for missing paths—not as a mandatory step for every initial MPIO deployment.^4^

Production impact

Claiming changes the driver stack through which the LUNs are presented, and the operation can require a restart. Microsoft explicitly warns that claiming storage after workloads are deployed can cause interruptions.^5^

Consequently:

• Expect the node being configured to lose access while it restarts.
• Do not run the broad claim simultaneously on both nodes.
• CSVs, the disk witness, and VMs should remain available only if the surviving node has healthy access to every LUN and retains quorum.
• A two-node cluster has no node redundancy during this work. Its witness is important because it participates in maintaining a voting majority.^6^

Microsoft requires the MPIO software, DSM software, HBA drivers, and HBA firmware to be identical across FC cluster nodes.^7^

Recommended rolling procedure

1. Before changing node 1
   • Confirm current backups and restore capability.
   • Have Hitachi verify the supported DSM/MSDSM choice, hardware ID, path policy, timeout values, HBA driver/firmware, zoning, and number of expected paths.
   • Confirm every CSV and the witness is accessible from both nodes.
   • Record:

Get-ClusterNode
Get-ClusterQuorum
Get-ClusterSharedVolume | Format-List Name,State,OwnerNode
Get-ClusterResource | Format-Table Name,State,OwnerGroup,OwnerNode
mpclaim -e
mpclaim -s -d

Get-ClusterQuorum reports the active quorum configuration and witness.^8^

2. Drain node 1

Suspend-ClusterNode -Name "Node1" -Drain

Confirm all VMs and cluster roles moved successfully and node 1 is Paused. Draining one node at a time is Microsoft’s documented rolling-maintenance pattern.^9^

3. Configure and restart node 1
   • Install/configure the selected DSM.
   • Add only the approved OPEN‑V hardware ID if using MSDSM.
   • Apply the claim and restart when required.
4. Validate node 1 before resuming it
   • Confirm the expected number of paths and that each LUN appears once through MPIO:

mpclaim -s -d
Get-ClusterNode
Get-ClusterSharedVolume | Format-List Name,State,OwnerNode
Get-WinEvent -LogName System -MaxEvents 200 |
  Where-Object Id -in 11,46,129,140,153,157

Also verify CSV paths under C:\ClusterStorage, witness state, VM storage access, and Hitachi path status. Then resume the node and test moving a noncritical VM or role to it.

5. Repeat for node 2 only after node 1 is healthy, resumed, and capable of owning workloads and storage.

Validation and duplicate identifiers

Do not run full storage validation against production CSVs or the witness while they are in use. Storage tests require selected clustered storage to be taken offline. Microsoft recommends presenting a small spare LUN from the same array to both nodes and using that for storage validation without disrupting production roles.^10^

The duplicate-identifier warning must be matched to the exact validation test or event:

• If multiple FC paths are being exposed as separate disks because no DSM claims them, correct MPIO claiming first.
• If this is Event ID 158 involving cloned VHD/VHDX files, that is a different issue; Microsoft documents Set-VHD -ResetDiskIdentifier for the affected VHD—not for SAN CSV or witness LUNs.^4^
• Do not change SAN disk signatures, initialize disks, format volumes, or run Set-VHD against cluster storage merely to clear the warning.

If CSVs, the witness, or paths do not return exactly as expected after node 1, stop before modifying node 2 and engage Hitachi support with the MPIO output, HBA/SAN logs, cluster validation report, and cluster logs.

References

1. Get-MPIOAvailableHW-Description
2. New-MSDSMSupportedHW-Description
3. Update-MPIOClaimedHW-Description
4. Multipath I/O (MPIO) troubleshooting guidance
5. Manage MPIO for Hyper-V hosts in the VMM fabric
6. What is a quorum witness?
7. Failover clustering hardware requirements and storage options
8. Get-ClusterQuorum-Syntax
9. Upgrade a Windows Server failover cluster with a cluster OS rolling upgrade
10. Validate hardware for a failover cluster