Live‑Migrate OpenStack Instances for Zero‑Downtime Maintenance

Why Live Migration Matters

Operators often need to perform hardware maintenance, firmware updates, or rebalance workloads without interrupting user‑facing services. Moving a running virtual machine to another compute node while keeping its network connections and memory state intact avoids the downtime that a traditional stop‑start cycle would cause.

Prerequisites for a Successful Live Migration

• Shared storage for the instance’s disks (e.g., NFS, Ceph, or a Cinder backend that is accessible from both source and destination hosts).
• Compatible CPU feature sets on the source and destination compute nodes; mismatched flags will cause the migration to abort.
• A Neutron network configuration that allows the instance’s traffic to follow it to the new host (typically a flat or VLAN network, or a provider network with appropriate segmentation).
• Matching libvirt/QEMU versions on both hosts; you can verify this with virsh capabilities or nova-manage cpu_info.

How the Process Works

OpenStack’s live migration relies on libvirt and QEMU/KVM. The hypervisor copies the virtual machine’s memory pages iteratively using a copy‑on‑write technique. As pages are dirtied during the copy, they are resent. Once the rate of dirty pages falls below a configurable threshold, the VM is briefly paused, the remaining state (including CPU registers and device state) is transferred, and the VM resumes on the destination host. Network connections remain attached because the Neutron ports stay bound to the same MAC and IP addresses.

Worked Example: Migrating an Instance

1. Ensure your OpenStack client is authenticated with a role that includes the nova:live_migrate permission (commonly admin or a custom role).
2. Run the migration command from any host where the OpenStack CLI is available:

openstack server migrate --live --host compute-02 web01

The legacy nova live-migration web01 compute-02 command behaves identically.

Monitor the migration’s progress:

openstack server show web01 -c status -c OS-EXT-SRV-ATTR:host

You should observe the status transition from ACTIVE → MIGRATING → ACTIVE, and the host field change from the source (e.g., compute-01) to the destination (compute-02).

For deeper insight, check the libvirt logs on both hosts:

grep -i migrate /var/log/libvirt/qemu/web01.log

Look for lines indicating memory transfer progress, dirty‑page rates, and any error messages.

Limitations and Trade‑offs

• Instances that use local ephemeral disks cannot be live‑migrated unless that disk is first moved to a shared backend (e.g., attached as a Cinder volume). Attempting to migrate such an instance results in a "Disk not shared" error.
• PCI passthrough, USB devices, or other host‑specific hardware require identical resources on the destination host; otherwise the migration will fail.
• During the memory‑transfer phase there is a temporary increase in network and I/O traffic as pages are shuffled between hosts.
• The brief pause at the end of the migration (typically a few hundred milliseconds) may affect latency‑sensitive workloads.

Actionable Closing

• Validate the procedure on a low‑risk instance in a non‑production cell before attempting it on production workloads.
• Automate recurring moves (e.g., nightly load‑balancing) with Heat orchestration or a cron job that invokes openstack server migrate --live --host <dest> <instance>.
• Monitor CPU, network, and storage utilization during the migration (using Ceilometer/Gnocchi, collectd, or similar) to spot abnormal spikes that could indicate a problem.
• Record any failures and update your host compatibility matrix (CPU flags, libvirt/QEMU versions, storage backends) to refine future migration decisions.