What Replaces vMotion and Storage vMotion When You Leave vSphere

Exit guides are written for the person choosing a platform. They compare hypervisors, count licence costs, and stop at the moment the decision is made. What almost none of them cover is the Tuesday after: the features your maintenance windows were built around, and what you type instead now.

For anyone who ran a VMware® estate, that list is short and specific. vMotion, to move a running VM off a host you need to patch. Storage vMotion, to move its disks off storage you need to retire. Storage DRS, to stop datastores filling unevenly. Cross-vCenter vMotion, for the awkward cases. EVC, to keep a mixed-generation cluster migratable at all. None of those words exist on the destination platform, which does not mean the capabilities are gone. It means the mapping is not one-to-one, and nobody hands it to you.

Two answers are worth having up front. vMotion has a direct equivalent, and its precondition is a storage property most default configurations do not provide. Storage vMotion has no direct equivalent, and that turns out to be the more interesting half, because on a pooled storage layer most of what it was invented to solve stops existing.

The feature-by-feature answer

Take the five features an admin actually depends on and translate them individually. Two of them are storage questions, one has no equivalent at all, and two are not storage problems in the first place, which is worth saying plainly rather than stretching an argument over them.

Table 1: The five vSphere features most likely to be missing from a destination-platform runbook.

The RWX row is the one that bites first. KubeVirt live migration works, and it works well, but it requires the VM’s disk to be attachable from the source and destination node simultaneously, which in practice means a StorageClass that supports ReadWriteMany in block mode. Most default StorageClasses hand out ReadWriteOnce node-local volumes, so live migration is silently absent until the first node drain, at which point the VM refuses to move and the volume reports itself already attached elsewhere. Nothing in the platform warns you at provisioning time. This is a storage-class decision that looks like a platform feature.

The last two rows are there to be honest about scope. Cross-vCenter vMotion maps onto moving a running VM between clusters, and that is not a problem the storage layer solves by itself: the target cluster needs its own scheduling, networking, and identity story, and the volume has to be reachable or replicated there. Anyone who tells you a storage product makes cross-cluster live migration trivial is selling. And EVC has nothing to do with storage at all. It is CPU feature masking, so its equivalent lives in node pools, labels, and scheduling constraints, and it belongs in your platform team’s backlog rather than this post.

That leaves the two rows in the middle, which are genuinely storage questions, and the second of them is where the design decision lives.

The four jobs Storage vMotion was actually doing

In vSphere, Storage vMotion presented as one thing: move a running VM’s disks to a different datastore. Underneath, it was carrying four workloads that have nothing to do with each other.

Job one, evacuation. A shelf goes out of support, a LUN is being retired, an array is being replaced. You point every VM on the old datastore at the new one, in sequence, without asking anyone for a maintenance window. This was the job that made Storage vMotion indispensable during hardware refresh.

Job two, rebalancing. A datastore fills, or a datastore gets hot. Storage DRS automated the response: given a datastore cluster, it handled initial placement for new disks and rebalanced existing ones based on space consumption and observed I/O latency. Its remediation action was, in every case, a Storage vMotion.

Job three, changing the disk’s shape. Thin to thick, thick to eager-zeroed thick. A provisioning-policy decision, carried out by rewriting the disk file somewhere else.

Job four, moving disks with the VM running. The mechanism is the interesting part. vSphere copies the disk’s blocks to the destination while mirroring the guest’s in-flight writes to both copies, then performs an atomic switchover once the copy has caught up. From inside the guest, nothing happened at all.

Two details from that list matter more than the rest, and both get lost when people summarize this operation as “moving a VM.”

The first is that vMotion and Storage vMotion are not the same operation. vMotion moves the VM’s memory and execution to another ESXi host and leaves the disks exactly where they are. Storage vMotion moves the disks and leaves the VM on the same host. The combined form does both at once. Teams who only ever thought in terms of “vMotion” tend to assume the new platform’s live migration covers the storage half too. It does not, and that assumption is where evacuation runbooks fall apart on their first rehearsal.

The second is that in all four jobs, the host did the copying. Bytes left the ESXi host’s storage datapath, crossed the fabric, and came back. That is why storage migrations were scheduled work rather than background work, and why “how many of these can I run at once” was a genuine capacity question rather than a config setting.

The destination platform splits those four jobs apart

On KubeVirt, and on Red Hat® OpenShift® Virtualization built on top of it, a VM’s disks are PersistentVolumeClaims. The four jobs land in four different places, and one of them lands nowhere at all.

Live migration moves the VM, not the data. Covered above, and covered in mechanism-level detail in our post on OpenShift Virtualization storage architecture. The point to carry forward is that the PVC is the same PVC before and after. No data is copied, which is exactly why it does not solve any of the four jobs.

Volume migration is the real analogue to Storage vMotion. Change which PVC, and therefore which StorageClass and which backend, a running VM’s disk is bound to, and let the platform copy the data and cut over. KubeVirt has added a declarative path for exactly this, and OpenShift Virtualization surfaces it as storage live migration. Both are comparatively recent and release-gated, so treat the capability as something to confirm against your own platform version before you write an evacuation runbook that depends on it. This is the single most important thing to verify early, because it is the difference between an online and an offline hardware refresh.

CDI cloning covers the offline path. A DataVolume with a PVC source clones an existing volume onto a different StorageClass. This is the mechanism most migration tooling was built against, it is the one with the longest track record, and it needs either the VM stopped or a snapshot to clone from. Our KubeVirt migration guide walks through the import mechanics in detail.

Disk format stops being an operation. Thin against thick, block against filesystem, replication factor, encryption, QoS: these are StorageClass parameters, not properties you convert in place. You do not rewrite a disk to change its shape. You provision from a different class, which folds job three back into job two, or you get the class right when the volume is created.

And then there is Storage DRS, which has no equivalent. There is no controller watching your StorageClasses, measuring space and latency across backends, and rebalancing volumes between them. If your vSphere design leaned on automatic capacity balancing across datastores, that dependency does not port upward into Kubernetes. It has to be satisfied underneath, inside the storage layer. The closest existing translation work is in our post on platform engineering after the VMware exit, which maps vSAN storage policies onto StorageClass tiers and DRS limits onto quotas plus volume-level QoS. What that post does for policy, this one does for the migration operations themselves.

Rehearsing an array evacuation on a platform that has no Storage vMotion? Talk to us before you write the runbook, not after the first migration window overruns. Talk to a storage architect

Where the bytes travel is the part that decides the cost

Put the four jobs next to their replacements and one column does most of the work.

Table 2: The four jobs behind one vSphere button, and what each one costs on the destination platform.

Every platform-level answer in the third column routes the copy through the compute node. The virt-launcher pod reads from the source volume and writes to the destination, which means the migration consumes CPU, memory bandwidth, and network on a node that is also running production VMs. That is the same constraint ESXi imposed, expressed in different vocabulary. Migrating fifty volumes off a retiring backend is fifty per-VM operations competing with the workloads those VMs are serving.

This is why “which platform feature replaces Storage vMotion” is the wrong first question. The right one is how many of the four jobs your storage layer removes from the VM’s problem space entirely.

Design so that most of those jobs stop being VM operations

The four jobs exist because a vSphere datastore is a unit of capacity welded to a set of hosts. Fill it and you must move something. Retire the hardware under it and you must move everything. Both are consequences of the coupling, not laws of storage.

When capacity is a pool addressed over NVMe/TCP or NVMe/RoCE instead of a set of host-attached datastores, the top two rows of that table change category. They stop being VM operations.

Adding capacity means adding devices or storage nodes to the pool. Existing volumes stay exactly where they are, addressed the same way, with the same PVC. Nothing is migrated, because nothing needs to move for the cluster to have more room. Retiring hardware means draining a storage node: the pool re-protects the affected data internally, at storage-layer speed, over the fabric, without traversing a single compute node and without any VM noticing. The evacuation that was fifty per-VM migrations becomes one storage-layer operation with no VM-side runbook at all.

Rebalancing follows the same logic. Because capacity is pooled rather than partitioned per datastore, there is no per-datastore fill level to chase, and QoS is a property of the individual volume rather than a side effect of which VMs happen to share a LUN. The thing Storage DRS was automating is not automated differently, it is designed out. Our post on Day 2 storage operations after the VMware exit covers how the surrounding snapshot and DR workflows change alongside this.

Two more properties follow from the same decoupling, and both matter when you are sizing the destination. Capacity and compute scale independently, so growing storage headroom does not mean buying compute nodes you do not need. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. The same volumes are addressable whether the hypervisor above is vSphere today, KubeVirt or OpenShift Virtualization next year, or bare-metal Kubernetes alongside both, which means the next platform move is a re-attach rather than another full data migration. That is the argument our post on replacing vSAN storage on OpenShift develops from the vSAN side.

None of this makes volume migration obsolete, and it would be a poor runbook that pretended otherwise. Two of the four jobs survive honestly. Moving a volume from a capacity tier to a low-latency tier is a real data movement, because the data genuinely has to end up on different media. Changing volume-level encryption is a real data movement for the same reason. Crossing into a different cluster or a different site is a real data movement. Those are the cases where you want the platform’s storage live migration capability confirmed, tested, and documented. The difference is that the list is short and predictable, rather than being triggered every time a piece of hardware ages out.

Which is the practical answer to the question in the title, and it is two different answers. vMotion is replaced directly, by live migration, provided you chose a StorageClass that can hand the same volume to two nodes at once. Nothing replaces Storage vMotion, because Storage vMotion was four jobs wearing one name: two of them you should design away in the storage layer, and two of them you should verify your platform can still do, and then rarely need. If you want the VM-side mechanics that sit under all of this, our guides to KubeVirt persistent storage and the KubeVirt and VMware comparison are the next two stops.

Questions and Answers

What replaces Storage vMotion on KubeVirt or OpenShift Virtualization?

No single operation does. Live migration moves a running VM between nodes without touching its data, volume migration (surfaced as storage live migration on OpenShift Virtualization) changes which PVC and StorageClass a running VM’s disk uses and copies the data, CDI cloning covers the offline copy path, and disk provisioning format becomes a StorageClass parameter rather than something you convert. The better design goal is to need those operations less: with simplyblock, capacity lives in a pool addressed over NVMe/TCP, so array evacuation becomes a storage-node drain and capacity rebalancing happens inside the pool, both without any per-VM migration and without copying data through your compute nodes.

Is KubeVirt live migration the same thing as Storage vMotion?

No, and conflating the two is the most common planning error in a VMware exit. KubeVirt live migration is the equivalent of vMotion: it moves the running VM to another node and leaves its volumes in place, which is why it requires the volume to be attachable from both nodes at once. Storage vMotion moved the disks, not the VM. If your runbook says “we will live-migrate off the old storage,” it is describing an operation that does not do that.

What replaces Storage DRS?

Nothing at the Kubernetes layer. There is no controller measuring space and latency across your StorageClasses and rebalancing volumes between backends. This is a genuine gap if your vSphere design relied on automatic datastore balancing, and the only sound answer is to satisfy it below Kubernetes: a pooled storage layer where capacity is shared across the whole pool has no per-datastore fill level to balance in the first place, and applies QoS per volume rather than per shared LUN.

Can I change the StorageClass of a disk on a running VM?

That is exactly what volume migration is for, and both KubeVirt and OpenShift Virtualization have added support for it. Confirm what your specific platform release supports before you depend on it, because the capability is recent and release-gated, and the offline CDI clone path remains the fallback. Note that the copy runs through the compute node in either case, so a large batch of concurrent migrations competes with the workloads on those nodes.

Is there an equivalent of cross-vCenter vMotion or EVC?

Partly, and neither is a storage answer, which is worth knowing before you scope the work. Cross-vCenter vMotion maps onto moving a running VM between clusters, and that needs scheduling, networking, and identity in the target cluster as well as a volume that is reachable or replicated there, so no storage layer solves it on its own. EVC is CPU feature masking and has no storage dimension at all; its equivalent is node pools, labels, and scheduling constraints. Treat both as platform-team items rather than storage-team items, and be sceptical of any product that claims otherwise.

How do I evacuate old storage hardware without a per-VM migration?

By not making the hardware a per-VM dependency. When volumes are provisioned from a pool over NVMe/TCP rather than from datastores tied to specific hosts, retiring hardware is a drain operation inside the storage layer: the pool re-protects the affected data over the fabric, and every PVC keeps its identity and its path. There is no VM-side runbook, no maintenance window per workload, and no migration traffic crossing your hypervisor nodes. That is the difference between a refresh measured in weeks of scheduled migrations and one measured in a single storage-layer operation.