Build1 publisher2 min readPublished
Nutanix Move 6.3's zero-copy ESXi-to-AHV path removes the copy step that forced validation
Nutanix Move 6.3, shipped July 29, 2026, moves VMs from ESXi to AHV by repointing array metadata instead of copying vDisk data. Teams that drop the copy step also lose the validation checkpoint it used to force, and they still carry identity and dependency risk.
The Engineer · Build desk
What happened
- Everpure FlashArray was the first array vendor to demonstrate the zero-copy integration publicly, at Nutanix .NEXT 2026.
- The offload path clones source vDisks through metadata pointers, provisions a new VM mapped to them, and boots it once the original VM shuts down.
- The same analysis notes that copy-based runbooks ran Copy, Validate, Compare, Cutover, and the copy step made those checks nearly free.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Runbooks that drop the copy step need an explicit post-conversion check written in, because the zero-copy mechanism no longer triggers one.
- constraint The staging and maintenance-window savings apply only to VMs whose vDisks already sit on a supported external array, so the benefit depends on where the data lives today.
- exposure Identity, dependency and survivability failures stay with the migration team, since none of them depended on how the bytes reached the target.
Move asks the array for new vDisks whose metadata points at blocks that already exist. Then it builds a VM around them [3]. No vDisk data crosses the wire [3]. A dev.to post that examined the release credits this with real savings: less staging capacity, less temporary storage held through cutover, a shorter maintenance window and less time spent watching a copy job [5]. The post says the gain is largest at the scale where copy-based migration bottlenecks on network throughput [5]. It does not include timing figures. For its list of savings to apply to a given estate, the vDisks have to sit on an array that Move's offload path supports [1]. FlashArray is the only one the post names [2].
The source VM survives the process. The new VM boots once the original shuts down. Because the original is preserved, a failed conversion can be backed out with no impact to the source environment [3][6]. I think that is a sound design choice. The post is careful to call it "a mechanism-native safety property, not a broader recovery guarantee" [6].
The post's sharper argument is about what the copy step did by accident. Copy-based runbooks ran Copy, Validate, Compare, Cutover, and the post says that sequence forced a checkpoint "that nobody had to design on purpose" [7]. Checksum comparison, byte-count verification and a boot test against the copied disk were nearly free because the copy had just happened [8]. A metadata repoint removes that event. The post states the problem plainly: "nothing about the mechanism requires it" [9].
The three old checks age differently. After a repoint, the source and target vDisks reference the same data blocks [12]. A checksum that compares a block with itself will pass every time. The boot test still tests something, because the target is a new VM on a different hypervisor [3]. In my view, a runbook should keep the boot test and rebuild the comparison step around what the conversion actually created: the VM definition and its mapping to the cloned vDisks [3].
The rest of the post's case is that identity, dependency and survivability risk, along with verification, were never a function of how the bytes moved, even under copy-based tooling [10]. Zero-copy leaves all four where they were. According to the post, many migration teams are reading the feature as risk reduction when it is a data-transfer optimization [11].
What to watch
- A published list of arrays supported by the Move 6.3 offload path beyond FlashArray.
- Measured cutover timings from teams running zero-copy conversions at scale, which would show how much of the maintenance window actually disappears.
- Whether Nutanix adds a built-in post-conversion validation step to Move.