Live Migration (or ANY migration!) is broken, I think due to buggered-up Network ATC config.

Use a structured approach to fix live migration while preserving Storage Spaces Direct and the existing VMs.

1. Verify the actual live migration error and cluster network state

• On one node, run in an elevated PowerShell session:

    Get-ClusterNetwork
  

• Confirm that:
  • All expected cluster networks (management, storage, etc.) are present.
  • For the networks that should carry cluster and live migration traffic, Allow cluster network communication on this network is enabled.
• If live migration errors show messages like:
  • “A cluster network isn't available for this operation. (0x000013AB)”
  • Or “Cluster network not found” then the cluster networks or live migration networks are misconfigured.

2. Confirm identical virtual switches on both nodes A very common cause of migration failures is a missing or mismatched virtual switch on the destination node.

• On each node, in Hyper-V Manager (or via PowerShell), verify that:
  • The virtual switch used by the VMs exists on both nodes.
  • The switch names are identical on both nodes.
• If a VM is connected to a switch that does not exist on the destination node, live migration fails at <10%.
• If needed, create or rename the virtual switch on the destination node to match the source node, then refresh the VM configuration and retry migration.

3. Check that Network ATC is managing live migration networks correctly Network ATC introduces intent-based management of cluster networks and live migration selection.

• Network ATC has a Live migration network selection feature:
  • When enabled (default), live migration networks are chosen based on the intents (for example, management_compute, storage).
  • If this logic is disabled, live migration network selection reverts to classic cluster behavior and must be configured manually.
• If the management_compute intent is partially satisfied or misapplied, the cluster may not correctly identify which networks to use for live migration.

Actions:

• On each node, verify Network ATC status:

    Get-NetIntentStatus
  

  • Ensure ConfigurationStatus is Success for all intents, including management_compute.
  • If any intent shows errors or is not applied, that must be corrected before relying on ATC for live migration.

4. Reconcile Network ATC configuration across both nodes (non-destructive to S2D) To avoid impacting Storage Spaces Direct, focus only on the network/intent layer and not on storage.

For each node in the cluster:

1. Pause and drain the node so that VMs are moved off it (as far as possible):

      Suspend-ClusterNode -Drain -Wait
   

2. Ensure any legacy or conflicting QoS/network configurations that pre-date Network ATC are removed (following the same commands used when the intents were first applied).
3. If VLAN IDs for virtual adapters under management_compute are incorrect or inconsistent between nodes, correct them using the same commands used when the intent was originally configured.
4. Ensure the virtual network adapters and underlying physical adapters have consistent naming across nodes using Rename-VMNetworkAdapter and Rename-NetAdapter (do not rename the vSwitch or re-add intents if they are already correct).
5. Make sure the Network ATC service is enabled and running on each node:

      Set-Service -Name NetworkATC -StartupType Automatic
      Start-Service -Name NetworkATC
   

6. Re-check intent deployment status:

      Get-NetIntentStatus
   

   • Confirm ConfigurationStatus is Success for all intents.
7. Resume the node:

      Resume-ClusterNode
   

8. Verify that all storage jobs are complete:

      Get-StorageJob
   

Repeat this process for each node. This sequence is designed to correct ATC-managed networking without touching S2D or CSVs.

5. Validate live migration configuration and test again After Network ATC and cluster networks are consistent:

• Confirm live migration settings in the cluster:
  • Ensure the networks intended for live migration are enabled and prioritized correctly.
  • If Network ATC’s Live migration network selection is enabled, verify that the intents (for example, storage networks) are the ones being used for live migration and that the management network is excluded if desired.
• Attempt a live migration of a single test VM:
  • If it fails with network-related errors, re-run Get-ClusterNetwork and verify that the networks used by ATC are marked to allow cluster communication and live migration.

6. If cross-site or stretched scenarios are involved If this cluster spans sites or subnets:

• Be aware that cross-site live migration is not supported in some Azure Stack HCI versions; the documented workaround is to:
  • Use quick migration for cross-site moves, or
  • Use a stretched VLAN (single subnet) as the preferred live migration network.

7. General Hyper-V live migration checks (if issues persist) If the above network and ATC checks look correct but migration still fails:

• Use a structured checklist:
  • Confirm all hosts are fully patched and supported.
  • Ensure VM configuration versions are consistent.
  • Verify that the same virtual switches exist and are identically configured on both hosts.
  • Confirm firewall rules and required ports (for example, clustering ports) are open.
  • Check authentication (Kerberos/CredSSP, SPNs, delegation) if using host-to-host live migration outside the cluster.

This approach keeps Storage Spaces Direct intact while systematically correcting Network ATC and cluster networking so that live migration can function again.

References:

• Configure Network ATC on Azure Local
• Troubleshoot live migration issues
• Troubleshooting guide: Hyper-V virtual machine live migration
• Manage Network ATC