top of page

DirectPath Migration for Nutanix Move 6.3.3

Writer: Taylor Norris
Taylor Norris
2 hours ago
3 min read
Infographic illustrating Nutanix Move 6.3.3 DirectPath Migration, enabling VMware ESXi virtual machines to migrate to Nutanix AHV or NC2 without requiring the VMware Virtual Disk Development Kit (VDDK). The diagram highlights direct VM data transfer, eliminating VDDK download and upload dependencies.

In August 2026, Broadcom restricted public access to the VMware Virtual Disk Development Kit (VDDK), a collection of libraries used by third-party backup and migration tools, including Nutanix Move, to access and transfer VMware virtual disk data. Previously, users could download VDDK directly from VMware's developer portal. However, Broadcom removed public download access, leaving many users encountering broken links or 404 errors. This created a significant challenge for organizations migrating workloads from VMware to alternative platforms like Nutanix AHV.


Nutanix addressed this dependency with Move 6.3.3.


Nutanix Move 6.3.3 introduces DirectPath, a data-copy migration method that directly accesses source VM disk data without requiring the VMware Virtual Disk Development Kit (VDDK). It supports ESXi-to-AHV migrations to on-premises Nutanix environments and Nutanix Cloud Clusters (NC2).

The practical change is straightforward: you no longer upload VDDK, but you do deploy Move inside the source VMware environment. Understanding that placement requirement is the starting point for a successful DirectPath migration.


What changes with DirectPath

In a VDDK-based migration workflow, Move requires the VMware disk-access library. DirectPath removes that dependency by giving Move direct access to the source VM disks through snapshot attachment.

Move must run on the source ESXi cluster or host and have visibility into the datastore containing those disks. Move temporarily attaches VM disk snapshots to its data mover, transfers the data, and manages the subsequent cleanup. The target-side data transfer uses NFS to write directly to the Nutanix cluster.


Technical architecture diagram of Nutanix Move 6.3.3 DirectPath Migration, showing VMware ESXi virtual machines migrating to Nutanix AHV or NC2 without requiring VMware VDDK. The diagram illustrates snapshot-based disk access, direct data copying to Nutanix Controller VMs (CVMs) over NFS ports 111 and 2049, and management connections to vCenter and Prism over ports 443 and 9440.

The overall migration workflow remains familiar: add environments, select VMs, map networks, prepare guests, seed data, and perform cutover. DirectPath changes the deployment model and disk data path.

DirectPath remains a data-copy migration. It does not eliminate network transfer, and Move 6.3.3 does not support zero-copy migration or in-place cluster conversion.


Build the network path to every target CVM

The DirectPath guide lists these required connections originating from the Move appliance on ESXi:

Destination

Required ports

vCenter

443

ESXi host

443

Prism Element or Prism Central

9440

All target Controller VMs (CVMs)

111 and 2049 for the NFS data path

 

Prism connectivity alone is insufficient. The Move appliance must reach all CVMs on the destination Nutanix cluster over NFS. Validate that path before beginning a migration wave.

The guide also states that migration data transferred through NFS is unencrypted by default.


Check the compatibility before creating the plan

There is also a compatibility detail worth checking carefully. The guide lists the below supported combinations:

·       vCenter 6.7, 7.x, and 8.x with ESXi 6.5, 6.7, 7.x, and 8.x.

·       Prism Element with AOS 7.5 and 7.6.

·       Prism Central 7.5 and 7.6.


Plan concurrency by disks

Move 6.3.3 documents these migration limits:

·       8 concurrent disks per ESXi host.

·       32 concurrent disks per Move instance when vCenter has more than four ESXi hosts.

·       100 VMs per migration plan.


Coordinate migrations with backup jobs

Move and VMware backup applications can both rely on Changed Block Tracking (CBT) and the VM snapshot chain. When one application deletes a snapshot, consolidation can temporarily lock the VM disks. The other application's attempt to access those disks can then fail.

Nutanix recommends avoiding backups while a Move migration is in progress and pausing Move migrations when a backup must run. Coordinate this with the backup team: establish non-overlapping schedules, maintain the agreed recovery posture, and confirm destination protection after cutover.



Read performance estimates in context

The guide provides the following selected test-environment estimates.

VM size

Disks

Target

Source latency

Target latency

Seeding

Cutover

1 TB

1

Prism Central

0.2 ms

0.5 ms

87 min

2 min

1 TB

1

Prism Element

0.2 ms

0.5 ms

91 min

2 min

1 TB

1

Prism Element

0.2 ms

260 ms

1330 min

5 min

3 TB

1

Prism Element

0.2 ms

0.5 ms

281 min

3 min

8 TB

8

Prism Element

0.2 ms

0.5 ms

690 min

4 min

 

These are published estimates, not results from my own lab, and they are not a commitment for your environment.



What I would verify before the first migration wave

·       A new Move 6.3.3 OVA is deployed on the correct source ESXi cluster or host.

·       Every selected VM datastore is directly accessible from that placement.

·       Management connectivity and NFS access to every target CVM are validated.

·       An IPsec VPN protects migration data crossing an untrusted or public network.

·       Encrypted VMs and unsupported migration paths are excluded.

·       Disk concurrency, backup schedules, and application cutover windows are agreed.


For partners helping customers transition to AHV, DirectPath removes the VDDK acquisition and upload dependency from supported ESXi-to-AHV migrations.


Sources



Comments


bottom of page