OpenStack has the ability to migrate volumes between back-ends. Migrating a volume transparently moves its data from the current back-end for the volume to a new one. This is an administrator function, and can be used for functions including storage evacuation (for maintenance or decommissioning), or manual optimizations (for example, performance, reliability, or cost).
These workflows are possible for a migration:
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, the Block Storage uses one of two generic flows, as follows.
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.
As an example, this scenario shows two LVM back-ends and migrates an attached volume from one to the other. This scenario uses the third migration flow.
First, list the available back-ends:
# cinder-manage host list server1@lvmstorage-1 zone1 server2@lvmstorage-2 zone1
Next, as the admin user, you can see the current status of the volume (replace the example ID with your own):
$ 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@lvmstorage-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 | +--------------------------------+--------------------------------------+
Note these 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 this volume's name on the back-end is based on. Before a volume is ever migrated, its name on the back-end storage may be based on the volume's ID (see thevolume_name_template
configuration parameter). For example, ifvolume_name_template
is kept as the default value (volume-%s
), your first LVM back-end has a logical volume namedvolume-6088f80a-f116-4331-ad48-9afb0dfb196c
. During the course of a migration, if you create a volume and copy over the data, the volume get the new name but keeps its original ID. This is exposed by thename_id
attribute.
Note | |
---|---|
If you plan to decommission a block storage node, you must
stop the On nodes that run CentOS, Fedora, openSUSE, RedHat 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 |
Migrate this volume to the second LVM back-end:
$ cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c server2@lvmstorage-2
You can use the cinder show command to
see the status of the migration. While migrating, 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 looks like:
+--------------------------------+--------------------------------------+ | 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@lvmstorage-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. If you look at the second LVM
back end, you find the logical volume
volume-133d1f56-9ffc-4f57-8798-d5217d851862
.
Note | |
---|---|
The migration is not visible to non-admin users (for
example, through the volume |
Note | |
---|---|
Migrating volumes that have snapshots are currently not allowed. |