VM: When Compute Moves but Data Stays

Our Head of Kubernetes, Chris Engelbert, presented “VM: When Compute Moves but Data Stays” at ContainerDays Hamburg 2026, held from September 2nd to 4th in Hamburg, Germany.

Live migrating a virtual machine in Kubernetes is easy. KubeVirt for the win. CPU registers, virtual system memory, all of it moved across to the target node while the workload keeps running. Same story on Red Hat® OpenShift® Virtualization.

But is that really all that matters?

What live migration actually moves

A running VM with CPU state, memory and storage, with Snapshot 1 carrying CPU state and memory to a stopped VM on the target node — Figure 1: Snapshot 1 carries the CPU state and the memory across. The storage bar stays where it is.

Your VM is running. It has CPU state, it has memory, and it has storage attached. KubeVirt snapshots the CPU state and the memory and starts copying that over to a stopped VM on the target node.

The source keeps running the whole time. That is the entire point of live migration, and it is also the complication: every page the VM touches after the snapshot is now stale on the target. So the source gets frozen, a second snapshot picks up only what changed, and that delta goes across. Much smaller than the first one. The target resumes, the source stops.

A frozen VM with Snapshot 2 carrying only the changed CPU state and memory pages to the target node — Figure 2: Snapshot 2 is the delta, only the pages that changed while the first snapshot was in flight.

Neat. Now look at what is still sitting on the old node.

The storage volume left behind on the source node while the resumed VM runs on the target node with only CPU state and memory — Figure 3: The VM is running on the new node. Its storage is not.

The storage. Compute moved, data stayed. And where that data actually lives decides what happens next.

So where does the data live?

Four answers, each with a price tag.

Local PVs

The fastest path to the disk, because there is no path. The volume is on the node. Which is also the problem: the volume is on the node. Local persistent volumes are hard to migrate and, live, close to impossible. Either the VM does not move, or something copies that volume first and you are not live anymore.

Shared storage

NFS on one side, SAN over iSCSI or Fibre Channel on the other. Both nodes see the same volume, so there is nothing to migrate. That part is solved.

The price is performance. Every I/O leaves the host and lands on the same appliance. No migration, but performance isn’t king.

Distributed storage

Spread the data across the cluster instead. Nothing to migrate here either, and redundancy comes along for free.

The price this time is the network. The blocks a VM wants are scattered across other nodes, so a read that used to be local is now a round trip. No migration, but you pay with network overhead.

Distributed storage with node affinity

Distributed storage, with one change: the VM’s data is placed on the node running the VM. Reads land on a local disk instead of crossing the network. Local-disk-like performance.

The other copies stay spread across the cluster, so losing a node does not lose the data. Distributed-disk-like reliability.

And then the VM host changes

Six data chunks spread across a cluster while the VM host has moved to a different node — Figure 4: The VM host moved. Most of the VM's data did not.

Because that is what Kubernetes does. This is normally where affinity falls apart. Node affinity says where the data should sit. It does not do anything the moment a VM lands somewhere else. The data is still reachable from the new host, over the network, which is not the same as local.

Unless the storage layer notices and realigns.

All six data chunks realigned onto the node now running the VM — Figure 5: The chunks realign onto the new host.

The data follows the VM to its new host, in the background, without anyone scheduling it. Transparent data realignment.

Moving compute is solved. Moving data is the interesting part.

Kubernetes has been rescheduling compute for years, and KubeVirt extended that to entire virtual machines. Storage is the layer that never caught up, which is why most platforms still run their most important workloads on something that quietly assumes nothing ever moves.

So, the short answer to the question in the title: when your workload moves, you should not be the one moving the data. The storage should follow the compute on its own.

Since we know that not everybody had the chance to join him, you can download the presentation now.