openstack-manuals/doc/admin-guide-cloud/source/compute-live-migration-usage.rst
Joseph Robinson 8e9507bf9a Moving .rst format files to main admin-guide-cloud folder
This change moves the .rst files into the main adming-guide-cloud
folder now conversion is complete. changes to the project config
and to the openstack manuals to stop sync of .xml files
are also needed.

Change-Id: I498e8d6ac3cb80da413e23b14a0959abd58e7d79
Implements: blueprint reorganise-user-guides
2015-08-21 09:37:08 +02:00

5.0 KiB

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.