Can OpenStack Nova live migration move a small application with zero user-visible downtime?

Answer

Yes – a small, mostly read-only application can be live-migrated with no perceptible downtime provided the migration pause stays below the TCP retransmission timeout (about 200 ms) and the instance meets the usual Nova live-migration prerequisites.

Confirmed facts

• Nova live migration copies memory and disk state while the VM runs, then pauses the VM briefly to transfer the remaining dirty pages.
• When the instance’s disks are on shared storage (Ceph, NFS, Cinder) the disk migration step is eliminated, so the pause is dominated by memory dirty-page transfer.
• Configurations that block live migration include CPU pinning (unless the destination CPU model is a superset), PCI/SR-IOV/GPU passthrough, hugepages or NUMA pinning that are not identically backed, and devices with pinned MAC addresses or VFs that cannot be migrated.

Likely explanation

For a small workload the memory dirty rate is often low (a few MB/s). On a 10 GbE link the remaining dirty pages can be flushed in under 10 ms, yielding a cutover pause of tens of milliseconds. Such a pause is shorter than typical TCP retransmission timers and keep-alive intervals, so existing TCP sessions survive without application-level reconnect and the interruption is imperceptible to users.

Steps needed for this case

1. Verify shared storage: from each compute node, confirm the storage backend (for example, ceph fs list or nfsstat -m) shows the instance’s disk images are present and readable.
2. Check CPU compatibility: run virsh capabilities on source and destination hosts and ensure the destination’s <cpu> element is a superset of the source’s.
3. Ensure no blocking devices: confirm the instance has no PCI passthrough, SR-IOV VFs, GPU passthrough, CPU pinning, hugepages, or NUMA pinning that would prevent migration.
4. Measure dirty rate (optional but recommended): use virsh domstats --balloon or virsh domblkstat to observe the memory dirty page rate; a rate below about 10 MB/s suggests a short pause.
5. Perform the migration: nova live-migration .
6. Monitor the pause: check /var/log/nova/nova-compute.log for the timestamps of the last pre-copy log and the post-migration resume log; compute the interval.
7. Validate TCP continuity: run a long-lived TCP test inside the instance (for example, iperf3 -c server -t 300) and verify no packet loss or reconnection during the migration window.

Missing diagnostic detail

If the memory dirty rate cannot be estimated beforehand, the migration pause length is uncertain. Measuring the dirty rate (step 4) is the single diagnostic detail that would change the recommendation: a high dirty rate could lengthen the pause beyond the TCP timeout, making zero-downtime unlikely without application-level reconnection logic.