Hyper-V VMs crash when any SAN volume is expanded

The fact that matching the VM role and storage owner makes the issue disappear points more toward a cluster-storage path problem than a guest operating system problem. I’d capture cluster, MPIO, and MSA logs during a controlled volume expansion, then correlate them with Event 5120 and any iSCSI or disk reset events. A short SAN pause can be enough to produce the guest’s critical-process crash if the storage path does not recover quickly.

The first thing I’d investigate is MPIO. An expansion triggers a storage rescan, and a problem with path configuration or failover handling could make the SAN briefly unavailable to the cluster. Verify that MPIO is installed and correctly configured on both nodes, including the HPE DSM or recommended vendor settings, and confirm that every path is visible and using the intended policy.

This sounds like the CSV may be entering a paused or redirected-I/O state during the volume expansion. When the VM and storage ownership are split, I/O may already be traveling through the cluster owner node, leaving less tolerance for a temporary SAN interruption. Check both nodes for Cluster Shared Volume Event 5120 at the exact time of the crash and review the CSV state and redirected I/O counters.

Also check the MSA controller and disk firmware. Expanding a LUN causes a target rescan, and an old controller firmware version can create an unusually long pause that makes the guest hit its disk timeout.

If these are Cluster Shared Volumes, check whether traffic is being forced into indirect or redirected mode. Confirm that the storage paths are correctly presented to both nodes and that the CSV filesystem and configuration are supported for your setup. ReFS and certain storage layouts can result in redirected I/O, so comparing the behavior and CSV state on NTFS versus ReFS may help narrow it down.