Rob Pankow 
Most VMware-to-Kubernetes migration guides walk through installing KubeVirt or Red Hat® OpenShift® Virtualization, importing a VM, and calling it done. What they skip is the part that actually determines whether the migration works: every VM disk has to become a PersistentVolumeClaim before the VM can boot, the cutover window has specific storage requirements that a generic StorageClass does not meet, and the rollback plan needs to be faster than re-running the import. This guide covers those three mechanics directly.
Why the Migration Path Is a Storage Decision, Not a Hypervisor One
A VMware VM’s disk lives as a VMDK on a datastore, addressed through vCenter and (for most production workloads) vSAN or an array. A KubeVirt VM’s disk lives as a PVC, provisioned through a StorageClass and attached the way any other Kubernetes volume is attached. Nothing about the hypervisor swap changes unless that underlying storage transition is deliberate.
That means the questions that actually decide whether a migration wave succeeds are storage questions: how fast can a disk import complete, what happens to a VM’s live migration eligibility once it lands on Kubernetes, and what is the recovery path if a cutover goes wrong. A hypervisor-only migration plan answers none of these, and finds out the hard way during the first production cutover.
Converting VMware Disks into KubeVirt DataVolumes
CDI, the Containerized Data Importer, is the KubeVirt component that turns a source disk image into a DataVolume, its custom resource for a PVC that is populated and ready for a VM to use. For a VMware migration, that source is typically a VMDK exported from vCenter or converted with virt-v2v, then imported through CDI as an HTTP, registry, or virtctl image-upload source. The open source Migration Toolkit for Virtualization (MTV) wraps this into a guided workflow for larger fleets, but the underlying mechanism is the same regardless of whether you drive it by hand or through MTV: an importer pod pulls the source image, converts it to raw or qcow2, and streams it onto the destination PVC.
That importer pod’s write pattern is a large, sustained sequential burst, not the small random I/O a running VM produces. One disk import is rarely the bottleneck. A migration wave of a dozen VMs importing in parallel is a different problem: a dozen simultaneous sequential-write streams landing on whatever StorageClass backs your cluster, competing for the same disks if that StorageClass is node-local. On generic local-disk storage, that contention is unpredictable, and it is usually the reason a migration wave that tested fine for one VM slips its maintenance window for twelve.
Sizing Storage for the Live Migration Cutover Window
VMware’s vMotion works over shared datastores, so every ESXi host in a cluster can already see a VM’s disk. KubeVirt’s live migration needs the equivalent: a volume that more than one node can attach to at once, which in Kubernetes terms means a StorageClass that supports the ReadWriteMany (RWX) access mode for block volumes. Most default StorageClasses back a PVC with ReadWriteOnce node-local storage, which is exactly what breaks live migration the first time an operator drains a node during a maintenance window post-cutover.
This is where a disaggregated, fabric-attached storage layer changes what “cutover window” means. Simplyblock exposes NVMe/TCP volumes that are reachable from any node in the cluster over standard Ethernet, so a DataVolume backed by simplyblock storage is RWX-capable without a clustered filesystem layered on top. A VM migrated onto that storage inherits live migration and node-drain behavior on day one, instead of discovering the limitation the first time someone tries to patch a node.
Planning a VMware-to-KubeVirt migration wave? Get the storage layer right before the first cutover, not after the first failed one. Talk to a storage architect
Snapshot and Clone as the Migration Safety Net
The instinct after a bad cutover is to treat the migration itself as reversible: shut down the KubeVirt VM, re-run the import from vSphere, try again. That only works if vCenter and the source VM are both still around, and it means re-streaming the entire disk a second time, the same slow sequential-write burst from the import step, now under time pressure with production down.
A CSI VolumeSnapshot taken immediately after the DataVolume import completes, before the VM is cut over to production traffic, turns that into a volume-level rollback instead of a re-import. If the cutover fails, restore the PVC from the snapshot and boot the VM again. No dependency on the source environment still existing, no re-conversion, no repeat of the slowest step in the whole migration. Simplyblock’s snapshot and clone operations run at the storage layer, so a rollback point costs a point-in-time metadata operation, not a second full data copy, which is the same day 2 pattern that applies after the migration is done, not just during cutover.
Choosing a Storage Layer for the Migration
The storage layer you land VMs on during the migration is the one you operate for years afterward, so it is worth choosing deliberately rather than defaulting to whatever StorageClass the cluster shipped with.
| Storage layer | RWX for live migration | Import throughput under a parallel wave | Rollback mechanism | Hypervisor portability |
|---|---|---|---|---|
| Node-local / hostPath | No (RWO only) | Degrades, disks contend for the same node | Re-run the import | Locked to that node |
| Shared network filesystem (NFS/CephFS) | Yes | Moderate, shared network path is the ceiling | Filesystem-level snapshot, if supported | Good |
| Simplyblock NVMe/TCP | Yes, fabric-attached | Scales with the pool, not one disk | CSI snapshot/clone, volume-level | Any hypervisor, no lock-in |
The structural difference is that simplyblock separates the storage pool from any single node, so RWX and import throughput are properties of the fabric rather than limits you hit per-disk. That is also what keeps the platform choice open afterward: the same NVMe/TCP layer works whether the destination is KubeVirt, Red Hat® OpenShift® Virtualization, or a future move off either one, with capacity-based licensing (per usable TB provisioned, not per CPU core) instead of a cost model that punishes scaling the cluster.
Questions and Answers
Does migrating a VMware VM to KubeVirt require a full disk copy, or is there a faster path? CDI’s import mechanism always reads the source disk once to populate the destination DataVolume, so the first copy is unavoidable. What you control is what happens after: with CSI snapshots on the destination, that first copy becomes the only full copy you need. Every rollback point afterward is a metadata-level snapshot or clone, not a repeat of the import.
Does KubeVirt live migration need shared storage the way vMotion does?
Yes. Live migration requires a volume more than one node can attach to, which in Kubernetes means a StorageClass supporting ReadWriteMany for block volumes. A default ReadWriteOnce node-local StorageClass will let a VM boot but will block live migration and node drains later. Fabric-attached storage like simplyblock’s NVMe/TCP pool provides RWX without requiring a separate clustered filesystem.
What happens if a cutover fails after the VM is already running on KubeVirt? If you took a CSI snapshot of the DataVolume right after the import and before cutting production traffic over, recovery is a snapshot restore, not a re-import from the original VMware environment. That matters most for large disks and for migrations where the source vSphere cluster is being decommissioned on a timeline.
Do I need the Migration Toolkit for Virtualization (MTV), or can this be done manually? MTV automates the CDI import workflow across a fleet of VMs and handles mapping networks and storage classes for you, which is worth using for anything beyond a handful of VMs. The underlying storage mechanics, CDI DataVolume import, RWX for live migration, and snapshot-based rollback, are the same either way.
Does this apply to upstream KubeVirt, Red Hat® OpenShift® Virtualization, or both? Both. OpenShift Virtualization is Red Hat’s productized distribution of KubeVirt, and the CDI import path, DataVolume model, and live migration storage requirements are the same underlying mechanics in either distribution.
