Moving a VM without downtime
If you run virtual machines, there comes a day when the host underneath needs maintenance. Live migration moves a running VM to another host while it keeps serving — no shutdown, ideally no one notices.
Live migration copies a running virtual machine from one host to another while it is still executing. Done right, the guest never stops — its memory is streamed across, then the last changes are caught up and execution hands over in a blink. It is how you do host maintenance without an outage for the VMs on it.
What it needs to work
- Shared or replicated storage both hosts can reach — the disk does not move, only the running state
- A fast, low-latency link between the hosts for the memory copy
- Compatible CPUs — migrating between very different CPU generations can fail or need a compatibility mode
How it actually happens
The hypervisor copies the VM’s memory to the target host while it keeps running, then copies the pages that changed during that copy, and again, converging until only a tiny amount is left. It pauses for a few milliseconds to move the last bit and the CPU state, then resumes on the target. A busy VM that dirties memory faster than the link can copy is the hard case — it takes longer to converge.
Storage is the quiet requirement
Live migration moves the running VM, not its disk. The storage must be reachable from both hosts — shared storage, or storage replicated between them — or there is nothing to resume from. This is why a migration plan starts with the storage design, not the VMs. See sharing files between servers and Proxmox.
What it does not solve
Live migration handles planned host maintenance gracefully. It does not save you from a host that crashes — there is nothing running left to migrate. For surviving sudden host failure you need real redundancy at the service level, not just the ability to move VMs politely. See high availability, honestly.
Sometimes a reboot is simpler
If a short maintenance window is acceptable, planning a brief reboot is far less machinery than keeping shared storage and migration working. Live migration earns its complexity when downtime genuinely is not an option — weigh that honestly. See planning a migration window.
Our side
When we do maintenance on virtualisation hosts we run, we migrate running guests off first where the setup allows it, so your VMs keep serving. If you run your own hypervisor on a dedicated server, the migration is yours to design — tell us if you want a second host and a storage layout that makes it possible.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base