Nutanix Move Management
Manage Nutanix Move migration plans, workloads, and network/storage mappings directly within Clarity Migrate. Track VM migration status without switching between tools.
Overview
The Nutanix Move Management module integrates Clarity Migrate with Nutanix Move — Nutanix's automated VM migration tool. It provides a single interface for defining migration plans, assigning VMs as workloads, configuring the network and storage mappings required for a successful migration, and tracking per-VM migration status — all without needing to switch between Clarity Migrate and the Nutanix Move console.
Clarity Migrate acts as the planning and governance layer, while Nutanix Move performs the actual VM migration. Status updates from Nutanix Move are synchronised back into Clarity Migrate so that the Command Centre always reflects the real migration state.
Plan — A Nutanix Move migration plan that links a source cluster (Provider) to a target cluster (Provider).
Workload — A VM assigned to a migration plan for migration.
Provider — A source or target cluster connection registered in Clarity Migrate (e.g. a VMware vCenter or Nutanix cluster).
Network Mapping — Maps a source port group or VLAN to its equivalent on the target cluster.
Storage Mapping — Maps a source datastore to a target storage container.
When to Use
- When migrating VMs using Nutanix Move — this module is the planning and tracking interface for all Nutanix Move-based VM migrations.
- When tracking multiple migration plans — if you have several cluster-to-cluster migration pairs running concurrently, the Plans list gives a unified view.
- When configuring network and storage mappings — ensure every source VLAN and datastore is mapped before migration begins to avoid VM network failures or incorrect storage placement.
- When running pre-migration readiness checks — use the Nutanix Readiness module to identify VM compatibility issues before starting Nutanix Move.
Key Features
Step-by-Step Instructions
Navigate to Migrations → Nutanix Move → Providers and click Add Provider. Enter the connection details for your source cluster (e.g. a VMware vCenter address, credentials, and cluster name) and target cluster (e.g. a Nutanix AHV cluster). Save each provider. Providers are reusable — configure them once and reference them in multiple migration plans.
Navigate to Migrations → Nutanix Move → Plans and click Add Plan. Enter the Plan Name (e.g. Wave1-ClusterA-to-ClusterB), select the Source Provider and Target Provider from the configured providers, and set the Planned Migration Date. Click Save. The plan is created and ready for workloads and mappings to be added.
Open the migration plan and navigate to the Workloads tab. Click Add Workload. Use the VM search to find devices from your CMDB — search by device name, IP address, or CMDB tag. Select the VMs you want to migrate in this plan. For each workload, optionally specify the Source Host (the current host the VM runs on) and Target Host (the desired placement on the target cluster). Click Save.
In the migration plan, navigate to the Network Mappings tab. Click Add Network Mapping. Select the Source Port Group (the VLAN or port group on the source cluster that your workload VMs are connected to) and map it to the equivalent Target Port Group on the target cluster. Repeat for every source VLAN used by any workload in this plan. Missing mappings will cause VMs to have no network connectivity after migration.
Navigate to the Storage Mappings tab within the migration plan. Click Add Storage Mapping. Select the Source Datastore and map it to the target Storage Container. Add a mapping for every source datastore that contains disks belonging to workloads in this plan. Without storage mappings, Nutanix Move will attempt to place disks on a default container which may not be the correct storage tier.
Before starting the migration, navigate to Migrations → Nutanix Readiness. Select the migration plan or the individual VMs you want to check. Click Run Readiness Check. The check validates each VM for Nutanix Move compatibility — including VMware Tools version, supported guest OS, and hardware version. Results show as Pass, Warning, or Fail for each VM. Resolve all Fail results and investigate Warnings before proceeding.
Once Nutanix Move begins migrating the workloads, return to the migration plan's Workloads tab in Clarity Migrate. Each VM shows its current migration status as synchronised from Nutanix Move: Pending, Seeding, Ready to Cut-Over, Cut-Over in Progress, Completed, or Failed. The PM can also monitor progress from the Command Centre, where Nutanix Move plans appear in the migration event's context.
Fields Reference
| Field | Level | Required | Description |
|---|---|---|---|
| Plan Namerequired | Plan | Yes | A unique name identifying the migration plan. Recommended format: WaveN-SourceCluster-to-TargetCluster (e.g. Wave1-ClusterA-to-ClusterB). |
| Source Providerrequired | Plan | Yes | The registered source cluster connection (e.g. VMware vCenter or Nutanix cluster) that workloads will be migrated from. |
| Target Providerrequired | Plan | Yes | The registered target cluster connection that workloads will be migrated to. |
| Planned Migration Dateoptional | Plan | No | The target date for cut-over execution. Used in the Command Centre Timeline and for reporting. |
| VM (Workload)required | Workload | Yes | The CMDB device record for the VM being migrated. Must exist in CMDB — workloads cannot be added for devices not in the CMDB. |
| Source Hostoptional | Workload | No | The specific host (hypervisor node) the VM currently runs on in the source cluster. Used for tracking and in the Readiness check output. |
| Target Hostoptional | Workload | No | The desired host placement in the target cluster. If not specified, Nutanix Move will place the VM according to DRS or default placement policy. |
| Source Port Grouprequired | Network Mapping | Yes | The source VLAN or port group that one or more workload VMs are connected to. Must cover every VLAN used by workloads in the plan. |
| Target Port Grouprequired | Network Mapping | Yes | The equivalent network on the target cluster that migrated VMs should connect to. Must exist on the target cluster before the mapping is created. |
| Source Datastorerequired | Storage Mapping | Yes | A datastore on the source cluster that contains VM disks belonging to workloads in this plan. |
| Target Containerrequired | Storage Mapping | Yes | The Nutanix storage container on the target cluster where migrated VM disks should be placed. |
Example Workflow
A Nutanix engineer is planning the first wave of a VMware-to-AHV migration. She has already configured two Providers: VMW-PROD-VC01 (source VMware vCenter) and NTX-PROD-CLU-01 (target Nutanix AHV cluster).
She creates a migration plan named Wave1-VMW-PROD-to-NTX-PROD, selecting the two providers and setting a planned migration date. She then opens the Workloads tab and adds 12 VMs from the CMDB, assigning each a target host based on the capacity plan.
She navigates to Network Mappings and adds 3 mappings: VLAN-100-Production → AHV-VLAN-100, VLAN-200-Management → AHV-VLAN-200, and VLAN-300-Backup → AHV-VLAN-300. All VLANs used by the 12 workload VMs are now covered.
She adds 2 storage mappings: PROD-DS-01 → NTX-CONTAINER-PROD and PROD-DS-02 → NTX-CONTAINER-PROD.
She runs the Readiness check. 10 VMs pass cleanly. 2 VMs flag warnings: both have VMware Tools version 10.1.x which is below the recommended minimum for Nutanix Move. She escalates to the Windows team, who update VMware Tools on both VMs. She re-runs the check — all 12 VMs now pass. She proceeds to execute the migration plan in Nutanix Move.
Tips
Always run Readiness checks before starting Nutanix Move migrations. Readiness issues discovered mid-migration (such as outdated VMware Tools or unsupported hardware versions) are far more disruptive than issues discovered in the planning phase. Readiness checks take minutes and can prevent hours of recovery work.
Network Mappings must cover every source VLAN used by your workloads. When reviewing your mappings, cross-reference the VLANs/port groups used by every VM in the workload list. A single missed VLAN will cause those VMs to have no network connectivity after migration — a critical production incident.
Use CMDB device records as the source of truth for workload selection. Only add workloads that exist as CMDB device records. This ensures that the migration is traceable from the CMDB through to the Nutanix Move plan, and that the Command Centre shows accurate progress.
Common Mistakes
Forgetting to configure Storage Mappings. Engineers frequently configure Network Mappings and then forget Storage Mappings entirely. The result is that VMs migrate successfully but their disks land on an incorrect default container, which may be the wrong storage tier for the workload (e.g. standard spinning disk instead of SSD-backed). Always configure both network and storage mappings.
Not running Readiness checks before migration. Skipping this step in the interest of saving time is a false economy. A Readiness check takes 5–10 minutes. Discovering a VMware Tools issue during a live cut-over window — when engineers are working to a tight schedule — can take 60+ minutes to resolve and may force a rollback.
Creating workloads for VMs not in the CMDB. Adding VMs directly by hostname or IP address rather than from the CMDB breaks traceability. The migration cannot be linked to the correct CMDB device record, move group, or migration event, which means it won't appear in the Command Centre and the audit trail is incomplete.