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

- Link: https://www.silviobalduzzi.com/en/2026/11/nutanix-move-directpath-without-vddk-multihomed/
- Published: 2026-11-03T18:44:15+01:00
- Author: balduz84

_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:

 1. Move takes a snapshot of the source VM’s disk.
 2. The snapshot disk is attached to the Move appliance as a local block device.
 3. 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.
 4. 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:

    ```wp-block-code
    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:

    ```wp-block-code
    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.

    ```wp-block-code
    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.

    ```wp-block-code
    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:

    ```wp-block-code
    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](https://next.nutanix.com/product-updates/nutanix-move-6-3-3-45958):
   announcement and release notes summary (Nutanix Community)
 * [Flexible VM Migrations to the Nutanix Cloud Platform with Move DirectPath](https://www.nutanix.com/blog/flexible-vm-migrations-to-the-nutanix-cloud-platform-with-move-directpath)(
   Nutanix blog)
 * [Move 6.0: Setting Up a Multihomed Environment](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v6_0:top-set-up-multihome-t.html)(
   Nutanix Portal)
 * [Nutanix Move 6.3](https://next.nutanix.com/product-updates/nutanix-move-6-3-45782)
   and [Nutanix Move 6.0](https://next.nutanix.com/product-updates/nutanix-move-6-0-44839)(
   Nutanix Community)