Nutanix Move without VDDK: DirectPath, what’s new in 6.x and the multihomed setup

Until a few weeks ago, every VMware migration with Nutanix Move started the same way: download the VDDK from the Broadcom portal and upload it to the appliance. Since the end of August that download is gone, and Nutanix has answered with Move 6.3.3 and a new migration method, DirectPath. Let’s look at how it works, what it requires, what the rest of the 6.x family brought and, while we’re at it, how to configure Move when it has more than one network adapter.

The problem: you can’t download the VDDK anymore

The Virtual Disk Development Kit (VDDK) is the VMware library that third-party products use to read VM disks on ESXi. Move relied on it for years to copy the disks of the source VMs, but the VDDK is not part of Move: since version 5.3.0 you have to download it from the Broadcom portal and upload it to the appliance before adding an ESXi environment as a source, picking the right version for your ESXi release (7.0.3.1 or 8.0.3.2 with the most recent versions of Move).

At the end of August 2026 Broadcom removed the public VDDK download pages. Customers who opened a ticket were told that the kit is no longer available for general use and is now reserved for technology partners, for backup and recovery products. This isn’t just a Nutanix issue: Red Hat MTV, Azure Migrate and several tools that migrate to KVM depend on the VDDK too.

For anyone planning their exit from VMware, this is a real roadblock: without the VDDK, Move up to 6.3 can’t copy disks from ESXi.

DirectPath: how it works

Move 6.3.3, whose release notes are dated October 13, 2026, introduces DirectPath: a method that transfers VM disk data directly from ESXi to AHV, without the VDDK. Nutanix calls it a special release, already GA, designed for ESXi-to-AHV migrations and for ESXi to ESXi on AOS.

According to the Nutanix technical blog, this is how it works:

Move takes a snapshot of the source VM’s disk.
The snapshot disk is attached to the Move appliance as a local block device.
Move reads the data at block level, regardless of the guest operating system’s file system, and copies it to the target cluster together with the VM configuration.
Once the copy is complete, Move detaches the snapshot disk from the appliance.

If you come from the vSphere backup world, you’ll recognize a pattern similar to the hot-add mode of backup proxies: an appliance that lives in the same environment and reads disks from snapshots. The Move workflow stays the same as always: you add vCenter or the ESXi host as a source, create the migration plan, sync and run the cutover. Only the VDDK step disappears: no download, no upload, no version to match with ESXi.

Requirements and constraints to know

The flip side is that the appliance must be able to reach the disks directly. That leads to a few constraints you should know before you start:

Move runs in the source vSphere environment. The appliance is deployed as a VM on ESXi, and the datastore holding the disks of the VMs to migrate must be accessible from the host where Move runs. With multiple clusters or non-shared datastores, you need to think about where to place the appliance, or how many appliances to deploy.
New deployments only. 6.3.3 can’t be installed as an upgrade from an earlier version, and upgrading from 6.3.3 to a later version isn’t supported either. For now the appliance is only available for ESXi: there is no AHV image.
No free-licensed ESXi. Hosts with a free license are not supported.
Two vCenter privileges to check. The account Move uses needs Provisioning › Allow virtual machine download and Cryptographic Operations › Direct Access. If the role dedicated to Move was created for an earlier version, review it.
Reserved networks. Move uses 172.17.0.0/16 and 172.18.0.0/16 internally: if they are part of your addressing plan, take that into account.

Compatibility

Component	Versions supported by Move 6.3.3
Nutanix AOS	6.10, 7.0, 7.3, 7.5, 7.6
Prism Central	pc.2024.3, pc.7.3, pc.7.5, pc.7.6
VMware ESXi	6.5, 6.7, 7.0 (Update 1–3), 8.0 (Update 1 and 3)
VMware vCenter	6.7, 7.0 (Update 1–3), 8.0, 8.0 Update 3, 9.0
Nutanix VirtIO	1.2.5

Known issues

Datastores with the same name. If two clusters in the same datacenter have datastores with the same name but different contents, a DirectPath migration can fail. The fix is to use unique names.
Cutover and cluster resources. If the target VM needs more resources than the cluster has available, the cutover fails and resizing it may not be enough: before retrying, delete the target VM that was already created from Prism.
CentOS 8.4 and 8.5 with Secure Boot. These VMs may not boot on AHV: you can disable Secure Boot or reset its keys from the boot manager.

One piece of data is still missing: a performance comparison with the VDDK. Nutanix hasn’t published one, so you’ll have to measure the timings in the field.

What else is new in the 6.x family

DirectPath is the headline feature, but the 6.x releases brought other interesting changes too.

Move 6.0 (September 2025)

In-place upgrade from 5.6.0; from 5.4.x and 5.5.x you move forward with a migration to the new appliance instead.
Migration of VMware NSX security policies to Flow Network Security.
The View Metrics dashboard, with the appliance’s health and performance in real time.

Move 6.3 (July 2026)

Direct migration into Prism Central Projects 2.0, together with the security policies.
Zero-copy migration from ESXi to AHV with supported external storage, and new arrays: Dell PowerStore and Pure Storage FlashArray.
Windows VMs keep their WINS settings and, on non-English systems too, their IPv6 settings.
A migration plan completes even if a single VM hits a problem during cutover.
Management from Prism Central 7.6, data migration to Federated Files Server, Nutanix GC2 on AWS GovCloud as a target, and CyberArk integration for credentials, in technical preview.

A practical note: 6.3 can be upgraded in place only from 6.0.x, 6.1.x and 6.2.0, while 6.3.3, as we’ve seen, is always a new deployment.

Move in a multihomed environment

When you need it

In many infrastructures the vSphere management network and the Nutanix CVM network are separate, and the firewall between them doesn’t let NFS traffic through. The natural solution is to give the Move appliance two network adapters: one facing vCenter and the ESXi hosts, one facing the CVMs of the target cluster. With DirectPath this scenario becomes even more common, because the appliance has to live in the vSphere environment but write to Nutanix storage.

Nutanix is clear, though: Move does not support multihomed environments. There is a workaround, documented in the Move 6.0 guide, that replaces with two manual steps what Move normally sets up on its own: allowing the Move IP on the target container through the filesystem whitelist, and mounting the container on the appliance at the path Move uses to write to it.

What to prepare

the second network adapter of the Move VM, already added and configured following the guide for your version;
the IP address Move uses to reach the CVMs, usually the one on the second adapter, and its subnet mask;
the CVM IP address;
name and UUID of the target container;
access to Prism Element and the password of the Move admin user.

The procedure, step by step

1. Create the migration plan. Log in to the Move UI, create a new migration plan choosing the target container, and save it without starting it.

2. Note the container UUID. If you don’t have it at hand, you can get it from a CVM, in the Uuid field of the output:

ncli ctr ls name=<tgt_contr_name>

3. Allow Move on the container. In Prism Element, choose Storage from the top menu and switch to the Storage Container view. Select the container, click Update, open Advanced Settings and scroll down to the Filesystem Whitelists field. Enter the Move IP with its subnet mask, in the <ip-address>/<netmask> format, and save. If you use more than one Move appliance, separate the addresses with a comma. To allow only the appliance, and not its whole network, I use the 255.255.255.255 mask:

192.168.20.50/255.255.255.255

4. Log in to the appliance as root. The documentation says to connect over SSH as root: in practice you log in as the admin user and switch to the root shell with rs, which asks for the admin password again.

ssh admin@<move_ip>
rs

5. Create the mount directory. Compared with the documentation I add -p, so the CVM folder is created too if it doesn’t exist yet.

mkdir -p /opt/xtract-vm/datamover/CVM_<cvm_ip>/<tgt_storage_container_uuid>

6. Mount the target container and check that the mount is active:

mount <cvm_ip>:/<tgt_contr_name> /opt/xtract-vm/datamover/CVM_<cvm_ip>/<tgt_storage_container_uuid>
df -h | grep datamover

7. Start the migration. Log out of the appliance and start the plan from the Move UI.

A few more tips

The mount doesn’t survive a reboot. It’s a manual mount, not written to /etc/fstab: if you restart the appliance, redo it before resuming the migrations.
One mount per container. The path includes the container UUID: if you migrate to more than one container, repeat steps 2 to 6 for each of them.
The container whitelist replaces the global one. Once it’s set, only the container whitelist applies to that container, not the cluster one. If the container is already exposed over NFS to other systems through the global whitelist, for example a backup proxy, add their addresses as well.
Clean up at the end. Once the migration is complete, unmount the container with umount and remove the Move IP from the whitelist: one less NFS access to keep an eye on.
It’s still a workaround. The procedure is in the Move 6.0 guide: check that it also appears in the guide for the version you use, or ask Nutanix Support to confirm, and try it first with a pilot VM.

How I would set it up in a project

New vSphere-to-AHV projects: Move 6.3.3 with DirectPath as the first choice, with a dedicated appliance in the source vSphere environment.
Existing appliances with the VDDK already uploaded: no rush to change. 6.3.3 can’t be upgraded, so I would treat it as a project appliance, deployed for the migration and decommissioned at the end.
Before the bulk migration: a pilot with representative VMs, Windows and Linux, with Secure Boot and with large disks, measuring sync and cutover times.
Preparation: a vCenter role updated with the two privileges, unique datastore names, no overlap with the 172.17 and 172.18 networks and, if the appliance has two adapters, the multihomed workaround ready.

With DirectPath, Nutanix removes the most fragile dependency on the path from VMware to AHV. The price is a special release with its own constraints: knowing them in advance makes the difference between a pilot that runs smoothly and one that gets stuck at the first migration plan.

References

Nutanix Move 6.3.3: announcement and release notes summary (Nutanix Community)
Flexible VM Migrations to the Nutanix Cloud Platform with Move DirectPath (Nutanix blog)
Move 6.0: Setting Up a Multihomed Environment (Nutanix Portal)
Nutanix Move 6.3 and Nutanix Move 6.0 (Nutanix Community)