Migrate instances¶

This section discusses how to migrate running instances from one OpenStack Compute server to another OpenStack Compute server.

Before starting a migration, review the Configure migrations section.

Migrating instances

1. Check the ID of the instance to be migrated:

   $ nova list
   

   ID	Name	Status	Networks
   d1df1b5a-70c4-4fed-98b7-423362f2c47c	vm1	ACTIVE	private=a.b.c.d
   d693db9e-a7cf-45ef-a7c9-b3ecb5f22645	vm2	ACTIVE	private=e.f.g.h

2. Check the information associated with the instance. In this example, vm1 is running on HostB:

   $ nova show d1df1b5a-70c4-4fed-98b7-423362f2c47c
   

   Property	Value
   ... OS-EXT-SRV-ATTR:host ... flavor id name private network status ...	... HostB ... m1.tiny d1df1b5a-70c4-4fed-98b7-423362f2c47c vm1 a.b.c.d ACTIVE ...

3. Select the compute node the instance will be migrated to. In this example, we will migrate the instance to HostC, because nova-compute is running on it:

   nova service-list

   Binary	Host	Zone	Status	State	Updated_at	Disabled Reason
   nova-consoleauth	HostA	internal	enabled	up	2014-03-25T10:33:25.000000
   nova-scheduler	HostA	internal	enabled	up	2014-03-25T10:33:25.000000
   nova-conductor	HostA	internal	enabled	up	2014-03-25T10:33:27.000000
   nova-compute	HostB	nova	enabled	up	2014-03-25T10:33:31.000000
   nova-compute	HostC	nova	enabled	up	2014-03-25T10:33:31.000000
   nova-cert	HostA	internal	enabled	up	2014-03-25T10:33:31.000000

4. Check that HostC has enough resources for migration:

   # nova host-describe HostC
   

   HOST	PROJECT	cpu	memory_mb	disk_bg
   HostC	HostC	HostC	HostC	HostC
   (total)	(used_now)	(used_max)	p1	p2
   32232	21284	21284	21284	21284
   878	442	422	422	422

   • cpu: Number of CPUs
   • memory_mb: Total amount of memory, in MB
   • disk_gb: Total amount of space for NOVA-INST-DIR/instances, in GB

   In this table, the first row shows the total amount of resources available on the physical server. The second line shows the currently used resources. The third line shows the maximum used resources. The fourth line and below shows the resources available for each project.

5. Migrate the instance using the nova live-migration command:

   $ nova live-migration SERVER HOST_NAME
   

   In this example, SERVER can be the ID or name of the instance. Another example:

   $ nova live-migration d1df1b5a-70c4-4fed-98b7-423362f2c47c HostC
   Migration of d1df1b5a-70c4-4fed-98b7-423362f2c47c initiated.
   

   Warning

   When using live migration to move workloads between Icehouse and Juno compute nodes, it may cause data loss because libvirt live migration with shared block storage was buggy (potential loss of data) before version 3.32. This issue can be solved when we upgrade to RPC API version 4.0.

6. Check that the instance has been migrated successfully, using nova list. If the instance is still running on HostB, check the log files at src/dest for nova-compute and nova-scheduler to determine why.