Using Migration

Before starting migrations, review the Configuring Migrations section.

Migration provides a scheme to migrate running instances from one OpenStack Compute server to another OpenStack Compute server. This feature can be used as described below.

First, look at the running instances, to get the ID of the instance you wish to migrate.

# 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 |
+--------------------------------------+------+--------+-----------------+

Second, look at information associated with that instance - our example is vm1 from above.

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

In this example, vm1 is running on HostB.

Third, select the server to migrate instances to.

# nova-manage service list
HostA nova-scheduler enabled  :-) None
HostA nova-network enabled  :-) None
HostB nova-compute enabled  :-) None
HostC nova-compute enabled  :-) None

In this example, HostC can be picked up because nova-compute is running on it.

Third, ensure that HostC has enough resource for migration.

# nova-manage service describe_resource HostC
HOST             PROJECT     cpu   mem(mb)     hdd
HostC(total)                  16     32232     878
HostC(used_now)               13     21284     442
HostC(used_max)               13     21284     442
HostC            p1            5     10240     150
HostC            p2            5     10240     150
.....

cpu:the number of cpu
mem(mb):total amount of memory (MB)
hdd:total amount of space for NOVA-INST-DIR/instances(GB)
1st line shows total amount of resource physical server has.
2nd line shows current used resource.
3rd line shows maximum used resource.
4th line and under is used resource per project.

Finally, use the nova live-migration command to migrate the instances.

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

Make sure instances are migrated successfully with nova list. If instances are still running on HostB, check logfiles (src/dest nova-compute and nova-scheduler) to determine why.

	Note
	While the nova command is called live-migration, under the default Compute configuration options the instances are suspended before migration. See the Configuring Migrations section for more details.

Log a bug against this page

Legal notices