Moving ESXi VMs to Nutanix AHV with Move: Prerequisites, Cutover and Guest Changes

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Nutanix Move makes a migration from ESXi to AHV look like one wizard, but it is three separate pieces of work: a block copy that depends on VMware's Changed Block Tracking, a set of changes made inside each guest, and a cutover that powers off the source. Most planning risk sits in the first two, because they begin well before the outage window.

The commands below were not run in a lab. They are taken from vendor documentation. VM names and disk numbers are examples.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Why it matters

Three documented behaviours can hurt a production VM before anyone has approved a cutover.

If CBT is not enabled on the source VM, Move enables it, and that deletes the VM's existing snapshots. Nutanix states the deletion is irreversible. Changed Block Tracking (CBT) is the VMware feature that records which disk blocks changed since a given point.

A source VM with RDM disks in physical compatibility mode has them converted to virtual compatibility mode during preparation, and by default Move shuts the VM down and restarts it to do so. If power cycle is not enabled, Move converts them with the VM powered on. This note covers data-copy migrations. An RDM (raw device mapping) gives a VM direct access to a storage LUN.

Backup software that disables or resets CBT during the sync causes the migration to fail, and the migration must be discarded and restarted from the beginning.

How it works

The components and the data path

Move is an appliance VM that orchestrates the migration. For ESXi to AHV it talks to vCenter directly, and VMware Tools "must be installed and up-to-date". It needs a VMware VDDK library uploaded to it, matched to the host version:

That table only matches libraries to hosts. The requirements page sets the floor: "The ESXi version must be 6.5 or later." The VDDK page's footnote rules out ESXi 5.5 as a provider, allowing only manual migration through vCenter 6.5 or later, and says any vCenter version can be used for the host. We follow the requirements page, so treat ESXi 6.0 as unsupported unless Nutanix confirms otherwise. The VDDK page lists no later ESXi release. Move's own supported-version table is in the release notes, which redirected to a sign-in page when we tried to open them, so confirm your exact ESXi and AOS releases there.

On-premises, Nutanix recommends deploying Move on the target AHV cluster, because writes are heavier than reads. Over a WAN it recommends the source side, because Move skips writing zero blocks, which makes reads the heavier direction across the link.

Move's internal Docker network defaults to 172.17.0.0/16. If your vCenter, hosts or Controller VMs live in that range, plan to change the bridge (Nutanix's guide points to KB-7135) before the first plan.

Network reachability

These rows come from Nutanix's Ports and Protocols list for Move and the ESXi requirements page:

A Controller VM (CVM) is the storage controller VM on each Nutanix node. "All" matters: a firewall rule for only the cluster virtual address does not meet the listed requirement.

Seed, delta, cutover

Move uses VMware snapshots and CBT to copy incremental changes during the Ready to Cutover phase. The first full copy is the seed. The VM stays running. Afterwards Move takes a snapshot at a set interval and applies the changes.

The interval is configurable per source provider, up to 72 hours for ESXi. Nutanix recommends performing the cutover within one week of the initial seed.

Concurrency has two separate limits, and they are easy to confuse:

• Seeding: at most 8 disks in parallel from a single ESXi host and 32 per appliance; the rest queue.
• Cutover: 10 slots per host, and a VM takes one slot per attached disk; the rest wait in Cutover Queued, first in, first out.

A plan holds at most 100 VMs, but the test-capable plan page says "You cannot add more than 50 VMs in a single migration plan." The pages disagree, so plan around 50 if you will use test VMs.

To estimate the seed, divide data size by a realistic rate. Nutanix's lab figures on 10 Gb networks range from 89 to 245 MBps. At 100 MiB/s, 10 TiB takes about 29 hours (10 × 1,048,576 MiB ÷ 100 ÷ 3,600). Measure your own path: Move documents running iperf3 from its containers, but that procedure needs a service restart with the caution that active migrations fail, so do it before the first plan starts.

What happens at cutover

The documented sequence for a data-copy migration is:

1. The VM enters Cutover Queued and waits if resources are unavailable.
2. Move powers off the source.
3. Move takes the final snapshot and copies the last changes.
4. Move adds a note to the source VM in vCenter.
5. Move disconnects the source VM's network interfaces.
6. Move creates the target VM and attaches the replicated disks.
7. The target VM is powered on or left off, matching the source's initial power state.
8. Scripts configure the static IP address, and the preparation scripts then reboot the VM.

The outage begins at step 2 and includes the reboot plus application and dependency validation. A running VM alone does not establish restored service.

Scheduling has sharp edges. The scheduled time is when cutover begins, not when it ends. An automatic or scheduled cutover fires only once: if it fails you must retry manually, except where a service restart caused the failure. A VM that misses its window reverts to manual cutover.

The DirectPath variant

Move 6.3.3 adds DirectPath, which reads disks directly and needs no VDDK upload. It is a choice made at deployment, because Move 6.3.3 does not support VDDK-based migrations. The advice above to deploy on the target and upload VDDK does not apply on this path, and the same page's requirements are strict:

• It is a new deployment only, on the same ESXi cluster or host as the VMs, and cannot be upgraded to or from.
• It excludes zero-copy, in-place cluster conversion, security policy and Nutanix Files migration.
• Sources are vCenter 6.7, 7.x and 8.x with ESXi 6.5, 6.7, 7.x and 8.x.
• The 32-disk appliance limit applies "when a vCenter Server has more than four ESXi hosts".
• You need one instance per ESXi cluster, even where a datastore is shared across clusters.
• Local datastores need an instance on the same host as the VM.
• Encrypted VMs and encrypted disks are not supported.
• Targets are listed as AOS and Prism Central 7.5 and 7.6.
• NFS carries the migration data unencrypted by default. Nutanix says to use an IPsec VPN if it crosses an untrusted network.

What Move changes inside the guest

Move has three preparation modes: Automatic, Manual, and Mixed, which appears when VMs in a plan use both. The same page lists what preparation does: install the Nutanix VirtIO driver, run an IP retention script, run a SAN policy script, and run a script to uninstall VMware Tools.

The Nutanix VirtIO package holds the balloon, Ethernet and SCSI pass-through drivers. A Windows VM that reaches AHV without the SCSI driver is likely to fail at boot, typically with INACCESSIBLE_BOOT_DEVICE (our inference, not a statement in the Move guide).

Windows credentials need care. The automatic-mode account needs Log on as a batch job ("Administrator users do not have sufficient rights"), the Move user needs a group holding Restore files and directories, and PowerShell 4.0 or later is required. Full support lists UAC as disabled, and Windows with UAC enabled is listed as data-only. The same page warns that UAC breaks the workflow if the built-in local Administrator is not used, and offers manual preparation as the alternative. Those statements leave room for interpretation, so test your standard Windows build first with a test VM.

Running third-party antivirus is listed as unsupported, because it blocks VirtIO installation and the IP retention step. IP retention on Windows releases earlier than Windows 11 and Server 2025 needs the WMIC utility present.

Linux needs 127.0.0.1 in /etc/hosts, root or sudo credentials, curl, and NSS 3.44.

IP retention has documented gaps. A VM with more than one interface may not keep every address, and a Windows VM keeps addresses only on connected NICs. Nutanix's plan page adds: "source IP configurations are applied correctly if the MAC address retention is applied from source VMs, otherwise best effort IP address configuration is done by mapping one NIC at a time." On a multi-NIC VM, select Retain MAC. A NIC left disconnected on purpose in vSphere is a planned manual step.

Disk naming is a Linux trap. Disks attached through a mix of PVSCSI and LSI adapters can receive different device names, and Nutanix says to correct fstab by hand. Mounting by filesystem UUID before the migration is the simplest protection.

Firmware

UEFI and Secure Boot have their own guest lists, different from the BIOS list. Read each guest against the correct table. On the 2026-11-04 text, Windows Server 2012 R2 is on the BIOS list but not the UEFI list, and Ubuntu 22.04 is on the UEFI list but not the Secure Boot list. RHEL 8.8 and 8.9 are not on the BIOS list. Windows 11 is on the UEFI list but not the BIOS list. The BIOS page says Windows 7 and Server 2008 R2 are not supported with UEFI on AHV, yet the UEFI list includes Windows 7, so check before relying on it.

For certain releases with UEFI, the boot device must be set manually after migration. Check your release on that page, because several entries carry footnote marks the text we read did not explain. AHV sets UEFI boot order with acli on a Controller VM while the VM is powered off:

acli vm.update_boot_device app01 boot_device_order=kDisk,kCdrom,kNetwork
acli vm.get app01

Power cycle the VM for the change to take effect. Secure Boot on AHV needs the Q35 machine type and VirtIO 1.1.6 or later, does not support IDE disks, cannot be enabled directly on a Legacy BIOS VM, and does not permit NIC hot-plug.

Move can convert a VM's virtual disks from IDE to SCSI during migration. To prevent that, Nutanix documents a /opt/xtract-vm/conf/tgtagent.json file on the appliance, set globally or per plan, followed by restart-tgtagent. Without the file, the custom configuration is off. Reserve it for VMs that must keep an IDE boot device. Nutanix lists "VMs requiring PCI or IDE bus" under data-only support, so unless the guest is listed for full support, such a VM loses the guest preparation described below. RHEL and CentOS 6.3 are fully supported only with IDE. AHV does not support Secure Boot on IDE disks.

What to choose and why

Use Automatic preparation where you can. On cancel or discard before cutover, Move cleans up automatically prepared source VMs. It does not clean up manually prepared ones. Keep Manual for VMs where you cannot supply credentials or must see the scripts first.

Treat data-only as a separate path. Data-only migration skips VirtIO installation, the IP retention scripts and the VMware Tools removal. It happens when you bypass guest operations, omit credentials in Automatic mode, or do not run the script in Manual mode. The page shows a warning only for Automatic mode, so in Manual mode an unrun script can change the outcome unnoticed. Data-only support requires you to install the VirtIO drivers yourself. When guest operations are bypassed, Nutanix requires that manual preparation "prior to cutover".

If you bypassed guest operations on Windows, the migrated disks appear as new, Move does not bring them online, and Nutanix gives this command:

echo san policy=OnlineAll | diskpart

Microsoft documents SAN policy as governing newly discovered disks, and warns that onlineAll on a server sharing disks can corrupt data.

Exclude what Move says to rebuild. Domain controllers and Exchange Server are unsupported for migration. Nutanix says to build a new domain controller and move the FSMO roles, and to migrate mailboxes to a parallel Exchange installation. Nutanix heads its next group "not recommended, but can be performed with some limitations". Database VMs move at VM level only, with no application changes or disk layout work, and Nutanix recommends adding vDisks and rebalancing data afterwards. For third-party appliances, it says to check AHV support with the vendor.

Screen the inventory early. ESXi-specific exclusions include PCIe pass-through, independent disks, multi-writer disks, 2 GB sparse disks, SCSI bus sharing and free-licensed standalone ESXi hosts. Other listed exclusions include guest operating systems with deduplication enabled, and VM names containing non-English characters or quotes. The VM needs hardware version 7 or later, and hosts must not be in maintenance mode.

Decide on backups in advance. The requirements page says to disable backups before migration. The backup page is softer: make sure the backup product does not toggle CBT, or do not schedule backups during the migration. Our recommendation is to keep a known-good restore point from before preparation starts, then follow the stricter wording during the sync.

Test before cutting over

Once a VM reaches Ready to Cutover you can create a test VM on the target, suffixed -MoveTest, while the source stays powered on. The Test Network field is optional, and it lists every network except the plan's target network. Use the test VM to prove the driver set, boot mode, disk order and application start. Then choose Remove Test VM and cut over. Always pick an isolated test network, because the test VM is a copy of a running server with the same identity.

A safe order of work

1. Export inventory. Sort VMs into Move-supported, data-only and rebuild.
2. Note which VMs have CBT off, because enabling it deletes their snapshots. Consolidating also removes the snapshots, and either way the loss is permanent, so record what they hold first.
3. Agree the backup position with whoever runs backups.
4. Deploy Move, upload VDDK, add the environments, and test network speed.
5. Build a small plan from representative guests and create test VMs.
6. Set the real plan, per-VM overrides and seed schedule.
7. Watch delta cycles and cut over inside the one-week recommendation.
8. Verify addresses, disks, Tools, boot mode and application health.

Risks and limits

Cleaning up a failed cancel. Preserve the plan identifier and failure logs, then use the installed Move version's supported cleanup procedure. Snapshot deletion, CBT changes, guest-driver removal and appliance-file deletion affect different systems and need separate object identification. A matching filename alone is not approval to remove storage.

Going back after cutover. The pages we opened do not describe a Move rollback once a cutover has completed. What they do say is that the source is powered off with its network interfaces disconnected. Returning to the source needs a separately validated recovery plan that excludes competing writers and accounts for all target-side transactions. A retained source is an older copy once AHV accepts writes, so restarting it alone would lose those changes. The source also stays prepared: the pages we opened do not say VirtIO is removed or CBT turned off after a completed cutover, so expect both to remain. With retained MAC and IP addresses, the two VMs must never run on the same network. This is our reasoning, not a Nutanix procedure, so test it on a non-critical VM.

Service restarts. Restarting the Move services makes active migrations fail, resets ongoing cutovers, and a management server restart stops scheduled migrations from beginning automatically.

Finding the evidence. For lost static addresses, guest logs are in C:\Nutanix\Temp on Windows and /opt/Nutanix/logs on Linux, present only where preparation ran.

Credentials and privileges. The vCenter privileges include Toggle disk change tracking, guest operations, power operations and snapshot management, and must be granted at user level, not group level. That account can change every VM it can see, so scope it and remove it after the project.

This article does not cover zero-copy migration on external FlashArray storage, NC2 targets, or Hyper-V sources. The vendor knowledge-base articles the guide cites were not opened.

Sources

Opened 2026-11-10.

• Nutanix Move 6.3 User Guide, individual sections linked inline
• Nutanix Ports and Protocols: Move
• AHV Administration Guide 11.2, VirtIO, UEFI and Secure Boot sections
• Microsoft: diskpart san

This article was originally published on 10 November 2026.