Rob Pankow 
A new wave of hyperconverged infrastructure (HCI) marketing is leading with “zero-copy” migration: converting a VMware VVol directly into the vendor’s own native virtual disk format in place, rather than copying every byte of guest data across the network during the cross-hypervisor conversion. It is a genuine engineering improvement over the older export-and-reimport migration path, and it is being marketed hard as the reason to pick that vendor’s HCI stack as the VMware exit destination.
What zero-copy migration solves is the one-time cost of the move: less data in flight, a shorter maintenance window, less risk during the cutover itself. What it does not solve is the storage architecture question sitting on the other side of that migration. Converting a disk format in place does not change what the destination storage fabric is coupled to. If that fabric is a single vendor’s proprietary hyperconverged stack, tightly bound to that vendor’s own hypervisor, the team has completed a fast migration into the same structural problem VMware and vSAN created in the first place: storage and compute sold as one inseparable unit, licensed and upgraded together, with no path off that fabric that does not look like another full migration.
What “Zero-Copy” Migration Actually Means
VMware’s VVol format stores a virtual disk as a set of objects on a vSAN or array-backed datastore, addressed through vSphere’s storage policy layer. A conventional migration off that platform exports each VM disk, typically as an OVF/VMDK bundle, then reimports it into the destination platform’s own format, a process that moves every byte of guest data across the network regardless of how large the disk is.
Zero-copy migration skips that data movement by converting the VVol’s underlying object layout directly into the destination hypervisor’s native virtual disk format, in place, using metadata operations instead of a full data copy. For a large VM disk, that is the difference between a migration measured in hours and one measured in minutes. It is a real reduction in cutover risk, and it directly targets the most commonly cited blocker to VMware exits: the operational disruption of moving hundreds or thousands of VM disks off vSphere at once.
The Trade Made After the Copy: Storage Coupled to One Hypervisor
The catch is what “native virtual disk format” means architecturally. A proprietary HCI stack’s virtual disk format is not a portable, open standard; it is an internal representation tightly coupled to that vendor’s own hypervisor and storage fabric, the same coupling model VMware used with vSAN. Converting into it in place is fast precisely because the storage layer and the hypervisor are designed as one unit. That is also what makes it a new lock-in, not an exit from lock-in.
Teams evaluating a zero-copy migration path are, in effect, choosing to repeat the vSAN pattern with a different vendor’s name on it:
- Storage and hypervisor sold as one SKU. Licensing, support, and roadmap all move together, the same bundling dynamic that made the original VMware/Broadcom licensing changes a forcing function for many exits.
- No format portability after the fact. Once data lives in a vendor-specific virtual disk format, moving off that platform later requires another full migration project, zero-copy or otherwise, rather than a storage-layer swap that leaves compute and the hypervisor choice untouched.
- Capacity and compute still scale together. Most proprietary HCI stacks keep storage capacity physically tied to compute nodes, so adding disk space still means adding or resizing hosts, the same constraint documented for hyperconverged storage generally.
None of this makes zero-copy migration a bad engineering feature. It makes it a partial answer to a bigger question: not “how do we move the data fast,” but “what should the data be coupled to once it lands.”
Weighing a zero-copy migration path against a Kubernetes-native storage layer for your VMware exit? A CSI-driven storage layer solves the same “avoid re-copying data” goal without tying the destination to a single vendor’s hypervisor. Talk to a storage architect
A Kubernetes-Native Alternative: CSI Snapshot and Clone Instead of Proprietary Disk Conversion
Kubernetes already has a standard mechanism for avoiding a full data copy during a storage-layer change: the CSI snapshot and clone interface. A CSI driver that supports snapshot and clone operations natively can reattach or fork a volume’s data without moving the underlying bytes, the same “convert the pointer, not the data” principle a zero-copy hypervisor migration relies on, except the mechanism is a portable Kubernetes API object instead of a single vendor’s proprietary disk format.
The practical difference shows up after the migration, not during it. A disaggregated or hyperconverged Kubernetes-native storage layer is not sold as one SKU with a specific hypervisor. It runs under KubeVirt, bare-metal Kubernetes, OpenShift Virtualization, or Harvester, and the same CSI driver provisions volumes regardless of which of those a team picks or later changes to.
| Attribute | Zero-copy proprietary HCI migration | Kubernetes-native CSI storage layer |
|---|---|---|
| Data-copy avoidance | In-place format conversion, vendor-specific | CSI snapshot/clone, standard Kubernetes API |
| Hypervisor coupling | Tied to that vendor’s hypervisor | Runs under any hypervisor or bare-metal Kubernetes |
| Capacity scaling | Coupled to compute node count (most stacks) | Independent of compute node count |
| Post-migration exit path | Another full migration project | StorageClass/CSI driver swap, no hypervisor change required |
| Deployment model | Hyperconverged only | Hyperconverged or disaggregated, same control plane |
Table 1: Zero-copy proprietary HCI migration versus a Kubernetes-native CSI storage layer.
The row that matters most a year after the migration is the last one. A team that lands on a Kubernetes-native storage layer keeps the option to run hyperconverged, storage and compute on the same nodes, or disaggregated, storage pooled separately over NVMe/TCP or NVMe/RoCE, without a second migration to change that decision later. A proprietary HCI stack does not offer that choice; the deployment model is the product.
Choosing a Storage Layer Without Committing to One Hypervisor
Simplyblock’s storage layer supports both deployment models from the same control plane: hyperconverged for teams that want storage and compute co-located the way vSAN did, and disaggregated for teams that want to scale storage capacity independently of compute. Either way, it integrates through the standard Kubernetes CSI interface, the same path covered for Harvester and KubeVirt, and works with vSphere, Hyper-V, bare-metal Kubernetes, KubeVirt, or OpenShift without requiring a specific one.
Pricing follows the same portability principle: simplyblock licenses per usable storage TB provisioned per year, not per CPU core and not tied to a specific hypervisor SKU. Adding compute nodes does not change the storage bill, and the storage layer does not require abandoning whatever hypervisor a team already runs, or plans to run next.
Migrating off vSphere is still, correctly, an urgent decision for many teams this year. The zero-copy marketing from proprietary HCI vendors answers a real question: how do you move the data fast. It does not answer the question that determines whether the next migration is five years away or five months away: what should that data be coupled to once it lands.
Questions and Answers
What does “zero-copy” mean in a VMware-to-HCI migration?
It means the destination platform converts a VMware VVol’s underlying storage objects directly into its own native virtual disk format in place, using metadata operations, instead of copying every byte of guest data across the network. It reduces migration time and cutover risk but does not change what the storage layer is architecturally coupled to afterward.
Does zero-copy migration reduce vendor lock-in?
No. Zero-copy migration speeds up the one-time move, but it lands the data in that vendor’s proprietary virtual disk format, coupled to that vendor’s own hypervisor. The lock-in shape is the same as the original VMware/vSAN coupling; only the vendor name changes.
How does a Kubernetes-native storage layer avoid a full data copy without proprietary lock-in?
It uses the standard Kubernetes CSI snapshot and clone interface to convert or fork volume references instead of copying underlying data, the same “convert the pointer, not the data” principle zero-copy migration relies on, but through a portable API any conformant CSI driver implements rather than one vendor’s internal disk format.
Can a Kubernetes-native storage layer run hyperconverged, like the vSAN model teams are migrating away from?
Yes. Simplyblock supports both hyperconverged (storage and compute co-located on the same nodes) and disaggregated (storage pooled separately over NVMe/TCP or NVMe/RoCE) deployment models from the same control plane, so a team can pick the model that fits without a separate migration to change that decision later.
Does switching storage layers require switching hypervisors?
No, for a CSI-driven storage layer. Because CSI is a standard interface, the same driver runs under vSphere, Hyper-V, bare-metal Kubernetes, KubeVirt, and OpenShift, so a storage-layer decision and a hypervisor decision are separate choices rather than one bundled purchase.
How is simplyblock priced compared to per-core HCI licensing?
Simplyblock licenses per usable storage TB provisioned per year, not per CPU core. Adding compute capacity does not change the storage bill, and the cost model does not require standardizing on a specific hypervisor or HCI vendor’s SKU structure.
