Warm migration: moving running VMs with seconds of downtime

The hardest part of leaving a virtualization platform isn't the destination — it's the journey. A 2 TB file server that takes six hours to copy is a six-hour outage if you migrate it cold. Multiply by a hundred VMs and "we'll migrate someday" becomes policy.

Warm migration changes the arithmetic. Here's how it actually works in SkyVirtHCI:

Copy while running

When you start a warm migration, the platform freezes a point-in-time view of each source disk and copies it over while the VM keeps serving users. This is the long part — hours for big disks — and it costs you nothing in availability.

Sync the changes, in shrinking rounds

Of course the VM kept writing during that copy. The connector then syncs just the changed data — and repeats, each round smaller than the last, until what's left is a few hundred megabytes. Then it parks and waits.

You choose the moment

Nothing happens until you say so. At the cutover moment you pick — 2 AM Sunday, the change window, whenever — the source VM shuts down, the final delta syncs, and the VM starts on SkyVirtHCI. In our testing the downtime clock from source-off to imported-and-booting reads in the teens of seconds.

And if something goes wrong?

This is the part we're proudest of. Before cutover, cancelling a warm migration — or any failure — leaves the source VM exactly as it was, still running; the platform cleans up after itself. Even after the cutover shutdown, a failure restarts the source VM intact rather than leaving you stranded between platforms. The source stays bootable until you decommission it deliberately. Rollback is a power button, not a restore job.

The migration guide covers the supported sources — vSphere, Hyper-V, oVirt, plain KVM hosts, VirtualBox — and a wave-by-wave plan that has worked in practice.