Hyper-V to Nutanix AHV Migration Guide: Nutanix Move, VirtIO Drivers, Veeam Cross-Platform Restore, and Cutover Planning

Migration Guide | Source: Microsoft Hyper-V | Target: Nutanix AHV | Audience: Infrastructure Architects, Migration Engineers

Migrating from Hyper-V to Nutanix AHV isn't the most common migration path in the series, but it's a real one. Nutanix has been actively pursuing Hyper-V shops as a consolidation target, and the pitch is compelling: replace a separate Hyper-V cluster and external SAN with a Nutanix cluster that bundles hypervisor, storage, and management into one platform. It has some specific gotchas that don't exist on the VMware-to-AHV path, particularly around Nutanix Move's Hyper-V support and the VirtIO driver requirement that catches people at cutover.

This article covers both migration paths available from Hyper-V to AHV (Nutanix Move and Veeam cross platform restore), cluster preparation, the VirtIO driver pre installation that you must not skip, cutover planning, and post migration validation.

1. Migration Path Decision

For most environments, Move is the right primary tool. Use Veeam cross platform restore as the fallback for VMs Move doesn't handle, for VMs that need careful cutover coordination, or when you want to validate the AHV environment with a non production VM before committing to Move for the full migration wave.

2. Cluster Preparation

Nutanix Cluster Requirements

• Verify the Nutanix cluster is on a current AOS version. Check the Nutanix compatibility matrix for the minimum AOS version required by the version of Nutanix Move you're deploying.
• Size the Nutanix cluster for the workloads you're migrating: total vCPU count, total memory, and storage capacity including the overhead for AHV's 20% storage efficiency reserve for Nutanix DSF operations.
• Configure networks in Prism that match the VLANs used by Hyper-V VMs. You'll map Hyper-V virtual switch port groups to Nutanix networks during the Move configuration. Get the VLAN tags right before starting migrations.
• If you're using Veeam cross platform restore, deploy the AHV Backup Proxy appliance on the Nutanix cluster. This is a Nutanix specific component that VBR uses to communicate with AHV. Without it, restore to AHV doesn't work.

3. VirtIO Drivers: The Pre Installation Requirement

AHV uses VirtIO drivers for virtual disk and NIC devices. Windows VMs migrated from Hyper-V don't have VirtIO drivers installed. If they arrive on AHV without VirtIO drivers, Windows can't see the AHV virtual disk after cutover and the VM won't boot. It's the most common failure point in Hyper-V to AHV migrations.

The fix is pre installing VirtIO drivers on Windows VMs while they're still running on Hyper-V, before migration. Nutanix Move can inject VirtIO drivers during migration, but pre installing them is more reliable and eliminates the risk of a failed driver injection leaving you with a non booting VM at cutover.

1. 1Download the Nutanix VirtIO drivers package from the Nutanix support portal. This is a Windows installer package, not individual INF files.
2. 2Install the VirtIO drivers on each Windows VM while it's running on Hyper-V. The installation doesn't change the active drivers (Hyper-V synthetic drivers are still active). It pre stages VirtIO drivers in the Windows driver store so they're available when the VM boots on AHV with VirtIO devices.
3. 3Verify the driver installation by checking Device Manager. The VirtIO devices should appear in the driver store without errors, even though they're not the active devices yet.
4. 4For Linux VMs, VirtIO drivers are typically already in the kernel. Verify that the virtio-blk and virtio-net modules load on boot: lsmod | grep virtio. If they're not present, add them to the initramfs and rebuild.

4. Migrating with Nutanix Move

1. 1Deploy Nutanix Move as a VM on the Nutanix cluster. Download the Move OVA from the Nutanix portal and import it into Prism. Move runs as a web accessible appliance.
2. 2In the Move UI, add your Hyper-V environment as a source. Move connects to the Hyper-V host (or System Center Virtual Machine Manager if you're using SCVMM for management) and discovers VMs.
3. 3Add your Nutanix cluster as the target. Move connects to Prism and discovers available networks and storage containers.
4. 4Create a migration plan. Select the VMs to migrate, map source networks to target networks, choose the target storage container, and configure whether Move should inject VirtIO drivers (set this to off if you've pre installed drivers manually).
5. 5Start the seed replication. Move begins copying VM data to AHV. This initial copy runs with the source VM still active on Hyper-V. Monitor progress in the Move UI.
6. 6When ready to cut over, trigger the cutover in Move. Move shuts down the source VM, performs a final delta sync to capture changes since the initial replication, and starts the VM on AHV. The cutover window is typically a few minutes for VMs with low write activity during seeding.

5. Cross Platform Restore with Veeam

If you're already using Veeam to back up Hyper-V VMs, you can use those existing backups to restore directly to AHV. Veeam v13 supports restoring VMs from Hyper-V backups to AHV without any intermediate conversion steps. This works as a migration path but it's not a live migration: the source VM runs normally during backup, then you shut it down, take a final backup, and restore that final backup to AHV.

1. 1Ensure the AHV Backup Proxy is deployed on the Nutanix cluster and registered with your VBR server. Without the proxy, the restore to AHV option won't be available.
2. 2Take a final backup of the Hyper-V VM after shutting it down for a clean, consistent restore point. Note the restore point timestamp.
3. 3In VBR, right click the Hyper-V backup and select Restore to Nutanix AHV. Select the target cluster, storage container, and network mapping.
4. 4After the restore completes, power on the VM on AHV and verify it boots and applications start. Don't power on the original Hyper-V VM after the AHV restore is complete.

6. Cutover Planning

Cutover is the window where the VM is down on Hyper-V and not yet confirmed running on AHV. Keep it short and have a rollback plan.

• Sequence VMs by dependency. Migrate infrastructure VMs (DNS, AD domain controllers) before application servers. Application servers before client facing services. Document the dependency order and migrate in reverse dependency order.
• Domain controllers need special handling. AD domain controllers have AD replication considerations. Don't seize FSMO roles during migration unless a DC failure forces it. Keep at least one DC running on Hyper-V during each migration wave until the AHV DCs are verified healthy.
• Rollback plan: For Nutanix Move migrations, the source Hyper-V VM is powered off at cutover but not deleted. If the AHV boot fails, power the Hyper-V VM back on. For Veeam cross platform restore, keep the original Hyper-V VM in a powered off state until the AHV VM has been running stable for at least one full business day.
• Update DNS. If VMs have static IPs that don't change in the migration (same IP on AHV), DNS updates aren't needed. If IPs change, update DNS records before declaring the migration complete and allow time for TTL expiration to propagate.