Live VM Migration in Harvester: Moving Running Workloads Without Downtime

The problem: patching a node without an outage window

You have a Harvester cluster running production VMs. A node needs a kernel update, a RAM stick is throwing ECC errors, or you simply want to rebalance load. The traditional answer is to shut down the VM, drain the node, and start the VM elsewhere. That means an outage window, a ticket, and a user asking why their service is down.

Harvester’s live migration feature removes that window. Powered by KubeVirt, it moves a running VM’s memory and device state to another node while the guest operating system keeps executing. The workload does not need to be stopped. The catch is that live migration is not magic: it depends on shared storage, compatible CPUs, and a network that can absorb the memory transfer. If any of those are missing, the migration will fail or stall.

How Harvester moves a running VM

Live migration in Harvester is a KubeVirt capability exposed through the Harvester UI and the Kubernetes API. When you start a migration, Harvester does not copy the virtual disk. Instead, it relies on a shared storage backend—typically Longhorn or NFS—that both the source and destination nodes can access concurrently. The VM’s disk stays where it is; only the in-memory state moves.

The process has three phases:

• Pre-migration: The source node begins copying memory pages to the destination while the VM keeps running. Pages that change during this phase are marked dirty and will need to be re-sent.
• Stop-and-copy: The VM is paused for a short interval—often under 200 ms—while the final dirty pages and device state are synchronized. The guest experiences this as a brief network hiccup, not a shutdown.
• Resume: The VM starts executing on the destination node using the shared disk and the transferred memory state.

Because the disk is shared, the migration does not need to copy gigabytes of data over the network. It only needs to move the working set of RAM, which is why a 10 GbE or faster network is usually recommended.

Three prerequisites that decide success

Before you schedule a maintenance window, verify these conditions. If one is missing, the migration will either be rejected or degrade into a long pause.

1. Compatible CPU features

KubeVirt compares the CPU model and feature flags on the source and destination nodes. If the destination lacks a feature the source exposes—say, an AVX-512 instruction or a specific virtualization extension—the migration is refused. Harvester will not start the transfer because the VM could crash after resuming on incompatible hardware.

You can relax this check by enabling CPU compatibility mode in the VM definition. That masks the destination CPU to look like a baseline model, which allows migration between heterogeneous nodes. The trade-off is that the guest loses access to newer CPU instructions, which may reduce performance for compute-heavy workloads.

2. Truly shared storage

The VM’s disk must live on a backend that supports concurrent read/write access from multiple nodes. Longhorn volumes and NFS exports meet this requirement. A VM backed by a node-local disk cannot be live-migrated; Harvester will report an error because two nodes writing to the same block device would corrupt data.

3. Network headroom

Migration traffic competes with VM traffic for bandwidth. If the link is saturated or latency spikes, the stop-and-copy phase can stretch from milliseconds into seconds, or the migration may abort entirely. Plan for a dedicated or prioritized 10 GbE path when migrating memory-heavy VMs.

Worked example: migrating a VM with kubectl

Assume a two-node Harvester cluster using Longhorn storage. Both nodes expose the same CPU vendor and feature set. You have a VM named web-prod-01 in the default namespace, and you want to move it from node-a to node-b.

Run the following from a workstation or jump host that has kubectl configured against the Harvester cluster. You need permissions to create VirtualMachineInstanceMigration objects, typically granted by the admin or edit role in the target namespace.

kubectl virt migrate web-prod-01 --namespace default

If your Harvester version exposes node selection through the CLI, you can add --target-node node-b. Otherwise, use the Harvester UI: open the VM, choose Migrate, and select the destination node explicitly.

To confirm the VM landed on the new node, query its status:

kubectl get vmi web-prod-01 -n default -o jsonpath='{.status.nodeName}'

You can also watch the migration object itself:

kubectl get virtualmachineinstancemigration -n default -w

While the migration runs, keep a terminal pinging the VM’s IP or curling its web service. A healthy migration produces at most a brief blip. If the ping drops for more than a second or the migration object reports Failed, check the KubeVirt and virt-handler logs on both nodes for network timeouts or CPU feature mismatches.

Trade-offs and limitations

Factor	Benefit	Limitation
Zero-downtime maintenance	Patch nodes without stopping VMs	Requires identical CPU features or compatibility mode
Shared storage dependency	No disk copy needed; fast migration	Local-disk VMs are excluded
Network sensitivity	Only RAM state moves	Saturated links cause long pauses or aborts

CPU compatibility mode is the most common compromise. It unlocks migration across mixed hardware, but it hides performance-oriented instructions from the guest. Benchmark your workload before and after enabling it if the VM runs HPC, AI inference, or other CPU-bound tasks.

Another limitation is that live migration does not solve every maintenance task. If you need to upgrade the KubeVirt version itself or change the storage backend, you may still need to schedule a brief outage. Treat live migration as a tool for node-level operations, not a universal zero-downtime guarantee.

Check your cluster before you need it

Live migration is easy to invoke and easy to get wrong if the foundation is missing. Before your next maintenance window, run through this checklist:

1. Confirm every VM you plan to migrate uses Longhorn or NFS storage, not a node-local volume.
2. Compare CPU models across nodes. In the Harvester UI, open each host page and check the CPU model string. If the nodes differ, decide whether compatibility mode is acceptable for your workloads.
3. Verify that the migration network can carry the expected memory throughput without starving VM traffic.
4. Test the full path on a non-critical VM first, using the commands above, and measure the pause time your workload can tolerate.

If those four items check out, you can drain a node for hardware repairs or OS updates while your users keep working. If they do not, fix the storage or CPU mismatch before you rely on the feature.