Migrating Volumes

Metacloud has the ability to migrate volumes between back-ends that support its volume-type. Migrating a volume transparently moves data from the current back-end for the volume to a new one. This migration can be performed for storage evacuation (for maintenance or decommissioning), or manual optimizations (for example, performance, reliability, or cost).

If the storage can migrate the volume on its own, it is given the opportunity to do so. This allows the Block Storage driver to enable optimizations that the storage might be able to perform. If the back-end is not able to perform the migration, Block Storage uses one of the two following work flows:

  • If the volume is not attached, the Block Storage service creates a volume and copies the data from the original to the new volume.

Note
While most back-ends support this function, not all do. See the driver documentation in the OpenStack Configuration Reference for more details.

  • If the volume is attached to a VM instance, the Block Storage creates a volume, and calls Compute to copy the data from the original to the new volume. Currently this is supported only by the Compute libvirt driver.

Example

The following example demonstrates two storage back-ends and migrates an attached volume from one to the other. This scenario uses the third migration flow.

  1. Run cinder get-pools to list the available back-ends.

     # cinder get-pools
     | Property | Value                     |
     |----------|-----------------------------|
     | name     | server1@storage-1#storage-1 |
    	
     | Property | Value                       |
     |----------|-----------------------------|
     | name     | server2@storage-2#storage-2 |
    	   
    

    Note
    You must be using the Block Storage API V2 to run the get-pools command.

  2. Run cinder-manage host list to get available back-ends. You must add the pool name, for example. server1@storage-1#zone1.

    # cinder manage host list
    server1@storage-1    zone1
    server2@storage-2    zone1
    
  3. Check the current status of the volume.

     $ cinder show 6088f80a-f116-4331-ad48-9afb0dfb196c
     | Property                       | Value                                 |
     |--------------------------------|---------------------------------------|
     | attachments                    | [...]                                 |
     | availability_zone              | zone1                                 |
     | bootable                       | False                                 |
     | created_at                     | 2013-09-01T14:53:22.000000            |
     | display_description            | test                                  |
     | display_name                   | test                                  |
     | id                             | 6088f80a-f116-4331-ad48-9afb0dfb196c  |
     |  metadata                      | {}                                    |
     | os-vol-host-attr:host          | server1@storage-1#storage-1           |
     | os-vol-mig-status-attr:migstat | None                                  |
     | os-vol-mig-status-attr:name_id | None                                  |
     | os-vol-tenant-attr:tenant_id   | 6bdd8f41203e4149b5d559769307365e      |
     | size                           | 2                                     |
     | snapshot_id                    | None                                  |
     | source_volid                   | None                                  |
     |  status                        | in use                                |
     | volume_type                    | None                                  |   
    

    Make note of the following attributes:

    • os-vol-host-attr:host—the volume’s current back-end.
    • os-vol-mig-status-attr:migstat—the status of this volume’s migration (None means that a migration is not currently in progress).
    • os-vol-mig-status-attr:name_id—the volume ID that provides the basis for the back-end volume name. Before a volume is ever migrated, its name on the back-end storage may be based on the volume ID (see the volume_name_template configuration parameter). For example, if volume_name_template is kept as the default value (volume-%s), your first storage back-end has a volume named volume-6088f80a-f116-4331-ad48-9afb0dfb196c. During the course of a migration, if you create a volume and copy over the data, the volume will get the new name but keeps the original ID. This is exposed by the name_id attribute.

    Note
    If you plan to decommission a block storage node, you must stop the cinder volume service on the node after performing the migration.

  4. Stop the cinder volume service. On nodes that run CentOS, Fedora, openSUSE, Red Hat Enterprise Linux, or SUSE Linux Enterprise, run:

    # service openstack-cinder-volume stop
    # chkconfig openstack-cinder-volume off
    

    On nodes that run Ubuntu or Debian, run:

       # service cinder-volume stop
       # chkconfig cinder-volume off
    

    Stopping the cinder volume service prevents volumes from being allocated to the node.

  5. Migrate this volume to the second storage back-end using the following command:

    $ cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c \ server2@storage-2#storage-2
    
  6. (Optional) Run cinder show to see the status of the migration. During the migration process, the migstat attribute shows states such as migrating or completing. On error, migstat is set to None and the host attribute shows the original host. On success, in this example, the output is as follows:

     | Property                       | Value                                |
     |--------------------------------|--------------------------------------|
     | attachments                    | [...]                                |
     | availability_zone              | zone1                                |
     | bootable                       | False                                |
     | created_at                     | 2013-09-01T14:53:22.000000           |
     | display_description            | test                                 |
     | display_name                   | test                                 |
     | id                             | 6088f80a-f116-4331-ad48-9afb0dfb196c |
     | metadata                       | {}                                   |
     | os-vol-host-attr:host          | server2@storage-2#storage-2          |
     | os-vol-mig-status-attr:migstat | None                                 |
     | os-vol-mig-status-attr:name_id | 133d1f56-9ffc-4f57-8798-d5217d851862 |
     | os-vol-tenant-attr:tenant_id   | 6bdd8f41203e4149b5d559769307365e     |
     | size                           | 2                                    |
     | snapshot_id                    | None                                 |
     | source_volid                   | None                                 |
     | status                         | in-use                               |
     | volume_type                    | None                                 |   
    

Note that migstat is None, host is the new host, and name_id holds the ID of the volume created by the migration. The second storage back end, contains the volume volume-133d1f56-9ffc-4f57-8798-d5217d851862.

Note
Migrating volumes that have snapshots is currently not allowed.

When a migration is in process, it is only visible to administrators through volume status and other indicators. Non-administrators cannot tell a migration is taking place. Some operations are not allowed while a migration is taking place, such as attaching or detaching a volume and deleting a volume. An error is returned if you perform one of these actions during a migration.