openstack/openstack-manuals
Code Issues Proposed changes
9b1e62e9cd
openstack-manuals/doc/admin-guide-cloud/source/compute-live-migration-usage.rst
Tom Fifield 884caa4a89 Liberty Release note/link updates for all guides 
Patch updates text areas and links to reflect the
Liberty release across all guides except the install
guide. Certain old notes relating to unsupported releases
were also removed.

Change-Id: I65f6e3747266db5b56e766d389376fb928d881c8
2015-10-13 14:09:07 +08:00

5.0 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_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.