openstack/openstack-manuals
Code Issues Proposed changes
08a2d82531
openstack-manuals/doc/admin-guide-cloud/source/compute-live-migration-usage.rst
Joe D'Andrea ea0affd36f Pivoted HostC table in Step 4 of Migrate instances. 
Table now better reflects output of nova host-describe.
Also added an extra row to match typical output.

Change-Id: I46f056626a4ee5fd939856b0ff30606396502266
Implements: blueprint user-guides-reorganised
Closes-Bug: 1524389
2015-12-15 17:06:39 +00:00

5.1 KiB
Raw Blame History

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.

Note

Although the nova command is called live-migration, under the default Compute configuration options, the instances are suspended before migration. For more information, see Configure migrations. in the OpenStack Configuration Reference.

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_gb
    HostC (total) 16 32232 878
    HostC (used_now) 22 21284 442
    HostC (used_max) 22 21284 422
    HostC p1 22 21284 422
    HostC p2 22 21284 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.