10.1 Nutanix Move: Cross-Hypervisor and Cloud Migration

10.1 Nutanix Move: Cross-Hypervisor and Cloud Migration

Objective 1.3 lists seven tools by name. Move is first, and it is the one customers encounter earliest, because almost every Nutanix deployment begins by moving workloads that already exist somewhere else.

What Move Is For

Move migrates running virtual machines onto Nutanix AHV from another platform. The problem it solves is that a VM built for one hypervisor will not simply boot on another: the virtual hardware is different, the storage and network drivers are different, and the guest operating system has drivers and configuration bound to the platform it was installed on.

Doing this by hand means exporting a disk image, converting it, installing drivers, fixing the boot configuration, and reconfiguring networking — per VM. Move automates that entire sequence.

Supported Sources and Targets

The recognition point for the exam: Move goes onto AHV, and it handles both on-premises hypervisors and public cloud instances as sources. It is a migration path into the Nutanix platform.

[!NOTE] Move is free. It is a Nutanix-provided tool downloaded from the Support Portal rather than a licensed add-on. That fact occasionally shows up as a distractor in licensing questions.

How Move Is Deployed

Move ships as a Linux-based virtual appliance. You deploy it as a VM on the target Nutanix cluster — commonly by importing its image through the Image Service and creating a VM from it — then manage it through its own web interface, separate from Prism.

Deployment sequence in outline:

1. Deploy the Move appliance VM on the target Nutanix cluster.
2. Open the Move web UI and add the source environment (vCenter, a Hyper-V host, an AWS account, or an Azure subscription) with credentials.
3. Add the target Nutanix cluster with Prism credentials.
4. Create a migration plan: select VMs, map source networks to target networks, and supply guest credentials where the guest needs preparation.
5. Start the plan, then cut over when the seeding has caught up.

The Migration Lifecycle

This is the sequence that makes the "minimal downtime" claim true, and it is worth knowing in order.

1. Validation

Move checks that each selected VM can actually be migrated: guest OS supported, disks readable, credentials valid, target capacity sufficient. Problems surface here rather than mid-migration.

2. Guest preparation

This is the step that makes cross-hypervisor migration work at all. Move installs the VirtIO drivers the guest will need to see its disks and network adapters on AHV, and adjusts boot and network configuration accordingly. On Windows guests this means the Nutanix VirtIO package; on Linux guests it means ensuring the appropriate modules are present in the initial ramdisk.

Preparation can be done automatically, if you supply in-guest credentials, or manually, if security policy forbids the tool logging into guests. If preparation is skipped or fails, the migrated VM will typically fail to boot on AHV — it cannot find its own disks. That symptom is a classic troubleshooting scenario.

3. Seeding and incremental synchronization

Move reads the source VM's disks and writes the data to the target cluster while the source VM keeps running and serving users. Once the initial copy completes, Move continues to replicate the changes accumulating on the source, keeping the target close behind.

This is why downtime is short: by the time you cut over, almost all of the data is already there.

4. Cutover

At a moment you choose, Move:

1. Shuts down the source VM.
2. Copies the final delta of changed data.
3. Creates and powers on the VM on AHV with the mapped networks.

The outage the users experience is roughly the length of steps 1 to 3, not the length of the whole data copy.

[!TIP] The exam-relevant sentence: the outage is the cutover, not the migration. Data movement happens with the source live; only the final delta and power-on require downtime.

What Move Is Not

Two boundaries are worth drawing clearly, because both make good distractors:

• Move is not a disaster recovery tool. It performs a one-way migration and finishes. Ongoing replication for recovery is the job of protection domains, Nutanix Disaster Recovery, or Multicloud Snapshot Technology — see section 5.3.
• Move is not a backup tool. It does not retain restore points, and it is not how you recover a deleted file. That is Self-Service Restore, snapshots, or a backup product.

Typical Exam Framing