Migrate "windows server failover cluster" vms from existing Hyper-V cluster to new Hyper-V cluster no shared storage

Question

To move “normal” standalone VMs is easy

But how does one move an existing “windows server failover cluster" VMs (2 VMs running SQL service in active/passive)

(That is VM only cluster with all shared storage as vhds)

from 2016 HV cluster with CSV on fibre storage to new 2025 HV cluster with local only S2D (so no shared storage between the, can’t even make it temporary, no space for extra cards)

Thanks

Seb

Answer 1

Sebastian Cerazy

That clarification makes the cold migration path significantly easier, though a zero-downtime Live Migration remains impossible because the hypervisors still do not share the underlying physical storage architecture. Since your 2016 environment is already encapsulating the shared storage inside VHD Set files rather than raw device mappings, you can cleanly transport the existing guest cluster without performing any storage conversions.

You must completely shut down the SQL roles and power off both 2016 virtual machines to release the file locks. Then copy the operating system virtual disks, the shared .vhds files, and any associated .avhdx backing files across the network directly into your 2025 Storage Spaces Direct Cluster Shared Volume, typically mapped to a path like C:\ClusterStorage\Volume1. Ensure you copy the entire VHD Set architecture intact to maintain the internal disk signatures that the guest Windows Server Failover Cluster relies on.

Once the files are fully staged on the 2025 infrastructure, you can recreate the virtual machines on the new cluster. Reattach the copied .vhds files to the virtual SCSI controllers of both new virtual machines, ensuring you configure them as shared drives. When you power the virtual machines back on, the internal guest cluster will recognize the original storage signatures and bring your active/passive SQL instance back online automatically. While this cold migration is now completely straightforward, deploying a side-by-side cluster and using SQL log shipping remains your only alternative if the file copy downtime exceeds your permitted maintenance window.

Domic

Answer 2

Hi Sebastian Cerazy,

Your new Windows Server 2025 Storage Spaces Direct cluster shares no underlying storage with the old 2016 fibre environment, the guest storage architecture must fundamentally change. Attempting a seamless storage or live migration will fail with Hyper-V Live Migration errors such as Event ID 21502, as the shared disks require continuous access to infrastructure that simply does not exist on the target side.

You should deploy two new virtual machines on your 2025 Hyper-V cluster and configure a new Windows Server Failover Cluster between them. For the shared SQL storage on the new infrastructure, you should provision VHD Set files, which utilize the .vhds extension, hosted directly on your new Storage Spaces Direct Cluster Shared Volumes. This replaces the legacy Shared VHDX format and properly supports host-level backups. Once this new infrastructure is operational, you can use native SQL Server tools like log shipping or a standard database backup and restore procedure to migrate your data from the old cluster to the new one with minimal cutover downtime.

If you must perform a cold migration to retain the exact existing virtual machines, you will face prolonged downtime and must carefully verify your current storage provisioning. If your 2016 virtual machines currently use Virtual Fibre Channel to connect directly to SAN LUNs, you cannot simply copy the data drives over the network. That raw volume data must first be backed up or captured into virtual hard disks. If your current shared disks are already standard virtual disks sitting on a host-level volume, you can completely power down the 2016 virtual machines, copy the operating system and shared data disks across the network to a path like C:\ClusterStorage\Volume1\ on your 2025 cluster, and attach them to newly created virtual machines while ensuring VHD Set sharing is configured on the target drives.

Hope this answer has brought you some useful information.

Domic V.

Answer 3

Migrating clustered SQL VMs from an older Hyper‑V failover cluster with Fibre Channel SAN to a new Hyper‑V 2025 cluster using local S2D (no shared storage between clusters) requires treating this as a cross‑cluster, no‑shared‑storage migration. The core points from the provided material:

1. Live migration does not move storage
   Live migration only moves the running VM between hosts/clusters; it does not move the VM’s VHDs/configuration storage:
   • “Live migration of a virtual machine doesn't migrate virtual machine storage, specifically meaning the location that stores the virtual machine images (VHD, ISO, VFD files).”
     Therefore, with no shared storage between the old SAN and the new S2D cluster, storage must be migrated separately.
2. Supported patterns for cross‑cluster moves
   From the VMM perspective, there are two broad options:
   • Live migration with shared storage (SMB 3.0 share common to both clusters). This is not available in the scenario because there is no shared storage between clusters.
   • Live migration with no shared infrastructure (storage migration plus VM migration). This is the applicable pattern here.
3. High‑level migration pattern for the clustered SQL VMs
   Given the constraints, the migration path is:
   1. Prepare storage on the new cluster
      • Ensure the new 2025 Hyper‑V cluster with S2D is fully configured and that CSVs / S2D volumes are ready to host the VM VHDs and configuration.
   2. Plan for temporary loss of high availability during migration
      • When migrating a VM between clusters, the VM temporarily loses HA status:
        “When you migrate a VM between clusters, note that the VM temporarily loses its high availability status. Therefore, a host failure during the migration causes the virtual machine to become unavailable.”
      • For SQL, this means planning a maintenance window and ensuring the AG/FCI or failover cluster roles are handled carefully.
   3. Migrate storage for each SQL VM
      Because there is no shared storage, use a storage migration mechanism to move VHDs from the SAN‑backed CSVs on the 2016 cluster to S2D CSVs on the 2025 cluster. In VMM terms this is a live storage migration from cluster storage to SMB 3.0 or to CSV on the destination cluster, as per the support matrix:
      • Source: Cluster → Destination: CSV (cluster) is supported when the CSV is available from the destination node.
        In practice, this typically means:
      • Expose the S2D storage via SMB 3.0 or otherwise make the destination CSV accessible to the source cluster node for the duration of the move.
      • Use storage migration (for example, VMM’s live storage migration or Hyper‑V Move-VMStorage) to copy the VHDs/configuration to the new cluster’s storage.
   4. Migrate the VM compute between clusters
      After storage is on the new cluster’s storage:
      • Use cross‑cluster live migration (supported when both sides are failover clusters and CSV is enabled) to move the VM from a node in the old cluster to a node in the new cluster:
        “Migration between clusters is only supported on hosts running in failover clusters. Cluster Shared Volume (CSV) storage must be enabled in the cluster.”
      • Ensure that the destination hosts meet live migration requirements (same CPU vendor, domain trust, private network for live migration, etc.).
   5. Re‑enable high availability on the new cluster
      • Once the VM is running on the new cluster and using S2D storage, configure it as a highly available VM in the new failover cluster (or via VMM, promote it to HA on CSV/S2D).
      • For SQL Server, reconfigure the Windows Server Failover Cluster role / SQL FCI or AG as needed so that both nodes of the SQL cluster are now the VMs on the new Hyper‑V cluster.
4. Networking and performance considerations
   • Use a dedicated or QoS‑controlled network for live migration traffic:
     “Use a dedicated network or VLAN for live migration traffic to ensure quality of service and for traffic isolation and security. Live migration traffic can saturate network links.”
   • Ensure all Hyper‑V hosts (old and new clusters) can access the live‑migration‑enabled network.
5. Summary
   With no shared storage between the old Fibre Channel SAN and the new S2D cluster, the move is a two‑step process: storage migration (copy VHDs/config to S2D) followed by cross‑cluster live migration of the VMs, then re‑enabling HA on the new cluster. During the transition, the SQL VMs will temporarily lose HA, so a carefully planned maintenance window and validation are required.

---

References:

• Migration of virtual machines – overview
• Network recommendations for Hyper-V in a failover cluster
• Windows Server storage architectures with Hyper-V
• Run a live migration in the VMM fabric
• Deploy a cluster set