Migration path authorization is the decision Nutanix Move 6.3.3 puts in front of an architect: who approves a VMware-to-AHV route that no longer depends on VDDK but still depends on privileged access to the source vCenter. The tooling question and the authorization question are different questions, and the release page only answers the first.
A migration plan built around VDDK has to account for access to that dependency. DirectPath introduces another route for the supported ESXi-to-AHV scenario, but it does not remove the need for migration path authorization: someone still has to approve the source-side privileges and deployment conditions that route requires.
What Nutanix Published on October 13
Nutanix described DirectPath in the Move 6.3.3 release notes, dated October 13, 2026. As published, it is a method for moving VM disk data directly between source and destination without requiring VDDK. It applies to ESXi-to-AHV migrations. For ESXi-sourced migrations, the page names two vCenter permissions: Provisioning, Allow virtual machine download, and Cryptographic Operations, Direct Access. It states that DirectPath is available on new Move deployments only, that it cannot be installed as an upgrade, that upgrading from 6.3.3 is unsupported, and that hosts running a free ESXi license are unsupported. A separate Nutanix article published October 16 describes the same release and is cited below where it adds to the record.
That is the subset of the release notes this post relies on. It is not a deployment-readiness checklist: the page carries further compatibility and limitation details, and the vendor's full compatibility and known-issues review stands separately. Treat the table below as the evidence ledger for migration path authorization, not as a risk assessment. Every row separates what the page says from what this post will not assert.
| Question | What the release page says | What this post does not claim |
|---|---|---|
| What is it? | A method for transferring VM disk data directly between source and destination without requiring VDDK | Anything about the data path from the release notes. They do not describe internals |
| Which direction? | ESXi to AHV | Any other source or target. This post stays on the ESXi-to-AHV scenario |
| What does the source side need? | Two named vCenter permissions for ESXi-sourced migrations | That the two permissions are sufficient, minimal, or the full reach of the account holding them |
| How is it deployed? | New Move deployments only. No install as an upgrade. Upgrading from 6.3.3 is unsupported | That any particular rollback path is unavailable |
| Which hosts? | Free-licensed ESXi hosts are unsupported | Behavior on any licensing tier beyond that statement |
| Availability status? | The release notes make no availability statement. The October 16 Nutanix article identifies Move 6.3.3 as generally available | That GA removes the new-deployment-only constraint or widens the supported scenario |
| Performance? | The page does not address performance relative to VDDK | Any advantage or penalty versus VDDK |
Sources: Nutanix Move 6.3.3 release notes and Flexible VM Migrations to the Nutanix Cloud Platform with Move DirectPath.
October 13 is the date of the publication that triggered this post. Neither it nor the October 16 article tells you when the feature became usable in your environment.
Migration Path Authorization Is Not the Access Question
Your VMware Exit Plan Assumed a Tool You Didn’t Control owns the VDDK dependency problem: a migration plan whose data path ran through a component under someone else's licensing terms. That post is about whether the tool is reachable. This post does not reopen it.
This post examines authorization of one specific migration route. If the VDDK-free route works in your environment, the dependency question changes shape. It does not disappear into a technical footnote. A route that avoids one component and requires a different set of privileged permissions on the source still has to be approved by someone, against some record, for some period.
The distinction matters in practice because approval is often assigned at the project level. "Migration approved" covers the program. It often does not say which data path is approved, which privileges that path consumes, and who can revoke them. Those three answers are what migration path authorization has to record. When a plan had one route, the route was implied. With two, it has to be stated.
What the Two Named Permissions Put in Front of a Reviewer
Start with what is published. Nutanix names Provisioning: Allow virtual machine download and Cryptographic Operations: Direct Access for ESXi-sourced migrations. A Broadcom knowledge base article describes Direct Access as required for console access to encrypted VMs. It does not tie the privilege to DirectPath, and it does not state the object level at which the privilege is assigned, so it does not establish what the privilege covers in this route. This post does not characterize what Allow virtual machine download permits beyond its name, because that description was not verified against a primary source.
What the permissions do not establish matters as much. They do not establish least privilege. They do not establish the effective reach of any particular account, which depends on the inventory objects the privileges are assigned to, how roles are propagated, and what else the account holds. They do not establish that logging and approval controls around the account are sufficient.
Those are open questions, and they are the reviewer's questions. A reviewer signing off on migration path authorization should be able to answer four of them in writing. These are recommended controls, not published facts.
Who holds the account. A named service identity, or a person's credentials reused for convenience. If the Move deployment authenticates to vCenter with a shared administrative account, the authorization record needs to say so.
What scope applies. Which inventory objects carry the two privileges, and whether the assignment propagates. The answer should come from the vCenter permission view, not from the migration plan.
How long access persists. Whether the privileges are assigned for a migration window and removed, or left in place after cutover.
Where activity is logged. Whether vCenter events for the account are retained somewhere the migration team cannot edit, and who reads them during a wave.
The named permissions say nothing about where they are assigned.
The Authorization Record
The route needs a written record before the first wave. That record is the working artifact of migration path authorization. It does not replace the vendor’s compatibility and known-issues review. Five parts are enough, and each one can be answered with a single paragraph.
01 — APPROVER
One named role with authority over the route, not the program. If the virtualization team, the security team and the migration vendor each assume another approved it, nobody did.
02 — PRIVILEGES AND SCOPE
The two named permissions, the identity that holds them, and the inventory objects they are assigned on. Record the scope as observed in vCenter.
03 — DURATION AND REVOCATION
When the privileges are granted, when they are removed, and who confirms removal after the last wave.
04 — TESTED RECOVERY OR ROLLBACK
The published constraint is new deployments only, with no in-place upgrade. That is an operational constraint, not a statement about recovery. Document the recovery or rollback procedure you have actually tested, including what happens to a Move deployment that has to be rebuilt mid-wave.
05 — UNKNOWNS WITH OWNERS
Performance against VDDK in your environment, how the documented data path fits your network and datastore design, and any support condition you have not confirmed with Nutanix. Each unknown gets an owner and a date by which it is answered or accepted.
The record ties back to the rest of the program. Route selection is one decision inside Virtualization Architecture, and the VMware Migration Strategy learning path covers where route selection sits in the wider sequence. The record above is the narrow piece that route selection leaves undone.
Two points on the fourth part. First, the new-deployment-only constraint changes what a rebuild means. It does not by itself say a rebuild is impossible or that recovery is harder than on the VDDK route. Nothing published supports either conclusion. Second, a tested procedure is the only version of this answer that counts. A plan to figure it out under pressure is the absence of an answer.
What the Published Sources Leave Open
The two Nutanix publications answer different questions, and the sources should stay separate.
Availability. The October 13 release notes do not state an availability status. Nutanix's October 16 article identifies Move 6.3.3 as generally available. That statement does not remove the new-deployment-only constraint in the release notes or widen the scenario they describe. The October 16 article does not restate the permissions or the deployment constraint.
Performance. Neither source addresses how DirectPath compares with VDDK. Do not assume it is faster, slower, or equivalent. If throughput drives your wave schedule, measure it on your own hosts.
Internals. The release notes do not describe how the transfer works. The October 16 article describes a snapshot-based, block-level read and a Move appliance running on the source vSphere environment. Those are Nutanix's statements, and each needs checking against your own network, datastore and placement design before it enters a design document.
None of these gaps weakens the case for writing the record. They are the reason the record has an unknowns section.
Architect's Verdict
The VDDK dependency was easy to write down because it was a single obstacle with a single owner outside the building. A second route removes that obstacle in the environments where it applies and replaces it with a decision that sits entirely inside the customer's own governance. That is a smaller problem in some ways and a more exposed one in others, because nobody else will force the question.
The question is migration path authorization: who approves the route, against what record. The two vCenter permissions Nutanix names are evidence that the route needs privileged source-side access. They are not a verdict on how risky the access is. That depends on the account, the scope, the duration and the logging, none of which the release page can tell you.
Performance is unaddressed in the published sources, and the fit of the documented data path to your environment is yours to confirm. Carry both as unknowns with owners, not as assumptions in either direction. A route is not approved because it avoids a licensing constraint, and it is not suspect because it is new.
Write the five-part record before the first wave. Name the approver, pin the scope to what vCenter shows, set the revocation date, test the recovery procedure, and assign each unknown to a person. If the record cannot be completed, migration path authorization has not happened and the route is not ready, whatever the release notes say about the transfer.
Additional Resources
- Virtualization Architecture — the pillar covering platform, hypervisor and migration decisions.
- VMware Migration Strategy — where route selection sits in the wider exit sequence.
- Your VMware Exit Plan Assumed a Tool You Didn’t Control — the VDDK dependency this route is meant to sidestep.
- Nutanix Move 6.3.3 release notes — the October 13 source for the permissions and deployment constraints.
- Flexible VM Migrations to the Nutanix Cloud Platform with Move DirectPath — Nutanix's October 16 GA announcement.
- Broadcom KB 384499: Direct Access and encrypted-VM console access — Broadcom's article on the Direct Access privilege.
Originally published at rack2cloud.com
Top comments (0)