Live migration of a virtual machine allow a VM executed by a certain compute node (which is going to fail or to be shutoff for maintenance), to be executed by another compute node with virtually zero downtime experienced by the virtual machine's users.

By default this operation can be performed only by the OpenStack admin user, which is the only one who has access to the mapping of virtual machines to the physical hypervisors (in fact admin can even force the creation of a virtual machine on a certain compute node; a normal user can't).

Other info are reported in the Remove a compute node HowTo

It is assumed that the nova instance lib directory (usually /var/lib/nova/instances) is remotely mounted by a gluster endpoint (or other shared file system), and that this guide has been followed to configure the compute node.

The command to live migrate a virtual machines from a hypervisor to another one is:

nova live-migration <instance_name_or_ID> <target_hypervisor_hostname>

• Note 1: <target_hypervisor_hostname> MUST be different from the current node running the virtual instances (use fully qualified name).
• Note 2: the virtual instance files (/var/lib/nova/instances) must be on a file system shared between the two hypervisors.
• Note 3: the status of the VM must be ACTIVE
• Note 4: it is strongly reccommended that both hypervisors have the same OS and libvirt version. It's possible to update an old libvirt with yum, but then you have to restart manually libvirtd, then the openstack-nova-compute service
• Note 5: it is possible to overcome the openstack "invtsc" CPU feature bug, deleting the invtsc section from the file /usr/share/libvirt/cpu_map.xml

If the migration fails, before retrying the migration command, reset the state of the VM

nova reset-state --active  11f98ac3-ee40-4735-b644-d2f2c7c176e7

If a VM is in SHOUTOFF status the command to be used is different and doesn't allow to choose the destination hypervisor:

nova migrate e14e276d-4594-481d-8cd1-c92831f06632

If the VM is in the VERIFY_RESIZE status, you must confirm through the dashboard the resize request; the VM now is ready to be migrated as a SHOUTOFF VM.

If the VM is PAUSED, the migration IS NOT POSSIBLE: the VM must be terminated or resumed via dashboard, then migrated; it is strongly recommended to contact the user and sync with him.

If the hypervisor of the VM is dead, use the command:

nova evacuate --on-shared-storage e14e276d-4594-481d-8cd1-c92831f06632 cld-nl-03.cloud.pd.infn.it

Pre-source code:

. keystone_admin.sh

Close a Compute Node:

nova-manage service disable cld-nl-02.cloud.pd.infn.it nova-compute
nova-manage service list | grep cld-nl

Compute Node VM list (Live Migration Helper Script):

[root@cld-ctrl-01 ~]# bin/vmListLiveMigHelper.sh cld-nl-01

Compute Node VM list:

nova list --host cld-nl-02.cloud.pd.infn.it --all-tenants

Compute Node resources:

nova host-describe cld-nl-02.cloud.pd.infn.it

VM details:

nova show 2ac6ec4b-eaf4-440a-aac4-46d3cdf6e19b

nova diagnostics <istanceName>