{"id":390,"date":"2026-08-30T01:25:51","date_gmt":"2026-08-29T23:25:51","guid":{"rendered":"https:\/\/nutanix.ma\/index.php\/2026\/08\/30\/migrating-vms-to-nutanix-ahv-with-move-a-field-walkthrough\/"},"modified":"2026-08-31T01:38:09","modified_gmt":"2026-08-30T23:38:09","slug":"migrating-vms-to-nutanix-ahv-with-move-a-field-walkthrough","status":"publish","type":"post","link":"https:\/\/nutanix.ma\/index.php\/2026\/08\/30\/migrating-vms-to-nutanix-ahv-with-move-a-field-walkthrough\/","title":{"rendered":"Migrating VMs from VMware cluster to Nutanix with Move"},"content":{"rendered":"

Nutanix Move is the free appliance Nutanix ships for migrating virtual machines onto AHV with minimal downtime \u2014 handling disk seeding, guest OS preparation and the final cutover in one workflow instead of a manual export\/import process. In a recent engagement we used Move to migrate a batch of production VMs from a VMware ESXi\/vCenter environment onto a Nutanix AOS cluster. This post walks through how the appliance was deployed and configured, how a migration plan comes together end to end, and two real errors we hit along the way \u2014 with screenshots from the actual project (customer identifiers, IP addresses and VM names have been redacted throughout).<\/p>\n

Deploying the Move appliance<\/h2>\n

Move ships as a virtual appliance and can be deployed either as an OVA directly in vCenter, or \u2014 as we did here \u2014 as a disk image imported straight into a Nutanix AHV cluster via Prism Element. In Settings > Image Configuration<\/strong> we created a new DISK image, uploaded the move-x.x.x.qcow2<\/code> file Nutanix publishes for each release, and pointed it at a storage container. Once the image finishes uploading, a VM is created from it and powered on to get the appliance running.<\/p>\n

\"Creating
Importing the Move appliance as a DISK image in Prism Element \u2014 an alternative to deploying the OVA in vCenter.<\/figcaption><\/figure>\n

First login and initial setup<\/h2>\n

The first time you open the Move web console you’re presented with the Nutanix End User License Agreement, which needs to be accepted before anything else is available.<\/p>\n

\"Nutanix
Accepting the EULA on first login to the Move appliance.<\/figcaption><\/figure>\n

Past the EULA you land on the VM Migration Dashboard. On a fresh 5.6.x deployment Move also surfaces a “What’s New” banner summarising the release \u2014 in our case IPv6 retention on several migration paths, VirtIO 1.2.4 support, and Microsoft Graph API support for Azure migrations.<\/p>\n

\"Move
The release notes dialog shown on first launch of Move 5.6.0.<\/figcaption><\/figure>\n

Migrating settings from an older Move instance<\/h2>\n

If you’re replacing an older Move appliance rather than starting from scratch, Move offers a one-click “Move Instance Migration” that pulls across all migration plans, configured environments, appliance settings and credentials from the previous instance, then automatically stops services on the old one once the transfer completes. A few things are called out as not<\/em> carried over \u2014 the SSH port, bandwidth cap policy and snapshot interval configuration have to be reapplied manually, and VDDK needs to be re-uploaded to the new appliance.<\/p>\n

\"Move
Move can migrate plans, environments and credentials from an older appliance in one step.<\/figcaption><\/figure>\n

Adding source and target environments<\/h2>\n

With the appliance up, the dashboard shows the three steps every migration follows: select source and target, add VMs to a plan, then run the migration.<\/p>\n

\"Move
The Move dashboard before any environments have been registered.<\/figcaption><\/figure>\n

The target is added first \u2014 a Nutanix AOS environment, which can point at either Prism Element or Prism Central, along with the admin credentials for that cluster.<\/p>\n

\"Add
Registering the Nutanix AOS cluster as the migration target.<\/figcaption><\/figure>\n

The source \u2014 our VMware vCenter \u2014 is added the same way. Once both are registered they show up side by side in the Environments panel, each listing how many VMs it can see.<\/p>\n

\"Environments
Source (ESXi\/vCenter) and target (AOS\/Prism Central) environments registered in Move.<\/figcaption><\/figure>\n

Uploading VDDK for ESXi sources<\/h2>\n

Migrating from ESXi requires VMware’s Virtual Disk Development Kit (VDDK) to be uploaded into Move \u2014 it’s what the appliance uses to read VMDKs during disk seeding. This is a one-time step under Settings > VDDK Upload<\/strong>; we kept both 7.0.3.1 and 8.0.3.2 uploaded to cover VMs across different ESXi\/hardware version combinations in the estate.<\/p>\n

\"VDDK
Two VDDK library versions uploaded and ready for use during migration.<\/figcaption><\/figure>\n

Building a migration plan<\/h2>\n

Everything from here happens inside a migration plan wizard. It starts with naming the plan.<\/p>\n

\"New
Every migration starts by naming the plan.<\/figcaption><\/figure>\n

Step one is source and target: pick the registered source environment, then the target cluster, an optional target project, and the storage container the migrated VMs’ disks will land on.<\/p>\n

\"Source
Selecting source, target cluster, project and storage container for the plan.<\/figcaption><\/figure>\n

Step two lists every VM Move can see in the source environment \u2014 datacenter, cluster, host, guest OS, power state and source network \u2014 so you can pick exactly which ones belong in this batch. Selected VMs collect in the “Added VMs” panel on the right, with any warnings flagged there too.<\/p>\n

\"Select
Choosing which VMs from the source environment go into this migration plan.<\/figcaption><\/figure>\n

Step three maps source networks to target networks on AHV, with an optional isolated test network for crash-consistent testing of the migrated VM before cutover.<\/p>\n

\"Network
Mapping the source VM network to its target network equivalent.<\/figcaption><\/figure>\n

VM preparation and guest credentials<\/h2>\n

Step four controls how Move prepares the guest OS for AHV \u2014 normally left on “Automatic,” which uninstalls VMware Tools, installs Nutanix Guest Tools (NGT), and retains the source IP configuration on the target VM. This step is also where credentials with administrator (Windows) or root (Linux) privileges are supplied, since Move needs to log into the guest to run the preparation steps.<\/p>\n

\"VM
Guest OS preparation settings and the credentials Move uses to log into each VM.<\/figcaption><\/figure>\n

VM settings: priority, timezone and migration type<\/h2>\n

The last configuration screen sets migration priority (which affects scheduling and bandwidth allocation when several plans run at once), the timezone applied to migrated VMs, whether to retain MAC addresses from the source, and any target categories to apply.<\/p>\n

\"VM
Setting migration priority, timezone and MAC address retention.<\/figcaption><\/figure>\n

It also decides how target VM properties are handled \u2014 either configured up front from the values captured at plan creation, or picked up fresh from the source at cutover time \u2014 and offers per-VM overrides plus an optional scheduled data-seeding start time.<\/p>\n

\"VM
Choosing between configuring target VM properties up front or retaining source properties at cutover.<\/figcaption><\/figure>\n

Monitoring migrations<\/h2>\n

Once a plan is running, the dashboard becomes the main thing you watch: counts of VMs In Progress, Ready to Cutover, Failed, Paused and Completed across every plan, with per-plan data size, migrated size and elapsed time.<\/p>\n

\"Move
The dashboard tracks every plan’s status and how much data has moved.<\/figcaption><\/figure>\n

Drilling into a plan shows individual VM progress \u2014 here a VM is 10% through data seeding with an estimated time remaining, which for large disks over a WAN link can run into hours.<\/p>\n

\"Data
Per-VM migration detail during the data seeding phase.<\/figcaption><\/figure>\n

As more environments and plans get added over the course of a multi-VM migration, the dashboard fills out accordingly \u2014 additional ESXi hosts and AHV\/Prism Central targets on the left, and a growing plan history on the right.<\/p>\n

\"Move
Additional source and target environments registered as the migration progressed.<\/figcaption><\/figure>\n
\"Move
Move also flags in the header when a newer appliance version is available.<\/figcaption><\/figure>\n
\"Move
Six plans running across the estate as the project moved through its batches.<\/figcaption><\/figure>\n
\"Move
Nine plans in total by the later stages of the migration, most completed successfully.<\/figcaption><\/figure>\n

Troubleshooting: two real errors from the field<\/h2>\n

Not every VM sails through on the first attempt. Two issues came up during this project that are worth documenting because they’re both easy to misdiagnose.<\/p>\n

1. “Not able to find File on VM\u2026 Got error while listing files at path”<\/strong> \u2014 one VM failed preparation with an authentication error and a file-not-found message pointing at a path under AppData\\Local\\Temp\\vmware<\/code>. This turned out to be a stale VMware Tools state on the guest: Move logs into the VM to stage its preparation payload in a VMware Tools temp folder, and if that folder is missing or the guest’s VMware Tools service is in a bad state, the file operation fails even though the credentials themselves are correct. Restarting the VMware Tools service (or reinstalling Tools where it was severely out of date) on the source VM before retrying the migration step resolved it.<\/p>\n

\"Move
A guest-side VMware Tools issue surfacing as a file-not-found error during VM preparation.<\/figcaption><\/figure>\n

2. “vCenter Server timed out during operation ‘ListProcesses’ for VM”<\/strong> \u2014 a different VM failed later, during the active migration phase, with a vCenter API timeout. Unlike the first error this wasn’t guest-side; it was vCenter itself taking too long to respond to a routine guest-operations call Move makes to track progress inside the VM. This is typically transient \u2014 caused by vCenter load, a slow ESXi host, or network latency between Move and vCenter \u2014 and in our case a straightforward retry of the migration cleared it on the next pass without any configuration changes.<\/p>\n

\"Move
A transient vCenter API timeout during migration \u2014 resolved with a retry.<\/figcaption><\/figure>\n

Wrap-up<\/h2>\n

End to end, Move turned what would otherwise be a manual, error-prone P2V-style migration into a repeatable workflow: register the environments once, build a plan per batch of VMs, let data seeding run in the background, and cut over with minimal downtime once everything is ready. The two failures we hit were both recoverable without touching the migration plan itself \u2014 one was a guest-agent hiccup, the other a transient API timeout \u2014 which is generally what to expect from Move issues in practice: check the guest’s VMware Tools health first, and treat vCenter timeouts as a cue to retry before assuming something is fundamentally broken.<\/p>\n","protected":false},"excerpt":{"rendered":"

Nutanix Move is the free appliance Nutanix ships for migrating virtual machines onto AHV with minimal downtime \u2014 handling disk seeding, guest OS preparation and the final cutover in one workflow instead of a manual export\/import process. In a recent engagement we used Move to migrate a batch of production VMs from a VMware ESXi\/vCenter […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-390","post","type-post","status-publish","format-standard","hentry","category-nutanix"],"_links":{"self":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/390","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/comments?post=390"}],"version-history":[{"count":2,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/390\/revisions"}],"predecessor-version":[{"id":431,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/390\/revisions\/431"}],"wp:attachment":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/media?parent=390"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/categories?post=390"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/tags?post=390"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}