34a567089b
This fixes mainly screens, computeroutput/userinput and also marks some filenames. A lot of prompts have been added. Change-Id: I864dc5b051bb297b61c9b2ed5464f9a35306bd68 Partial-Bug: #1217503
155 lines
9.5 KiB
XML
155 lines
9.5 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xml:id="volume-migration"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0">
|
|
<title>Migrate volumes</title>
|
|
<para>The Havana release of OpenStack introduces the ability to
|
|
migrate volumes between backends. Migrating a volume will transparently
|
|
move its data from the volume's current backend 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).</para>
|
|
<para>There are three possible flows for a migration:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>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 may be able to
|
|
perform. If the backend is not able to perform the
|
|
migration, Block Storage will use one of two generic
|
|
flows, as follows.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>If the volume is not attached, the Block Storage
|
|
service will create a new volume, and copy the data from the
|
|
original to the new volume. Note that while most backends
|
|
support this function, not all do. See driver documentation in
|
|
the <citetitle>OpenStack Configuration Reference</citetitle> for
|
|
more details.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>If the volume is attached to a VM instance,
|
|
the Block Storage service will create a new volume,
|
|
and call Compute to copy the data from the original
|
|
to the new volume. Currently this is supported only
|
|
by the Compute libvirt driver.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>As an example, we will show a scenario with two LVM
|
|
backends, and migrate an attached volume from one to the
|
|
other. This will use the 3rd migration flow.</para>
|
|
<para>First, we can list the available backends:
|
|
<screen><prompt>$</prompt> <userinput>cinder-manage host list</userinput>
|
|
<computeroutput>server1@lvmstorage-1 zone1
|
|
server2@lvmstorage-2 zone1</computeroutput></screen>
|
|
</para>
|
|
<para>Next, as the admin user, we can see the current status
|
|
of the volume (replace the example ID with your own):</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder show 6088f80a-f116-4331-ad48-9afb0dfb196c</userinput>
|
|
<computeroutput>+--------------------------------+--------------------------------------+
|
|
| 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 |
|
|
+--------------------------------+--------------------------------------+</computeroutput></screen>
|
|
<para>Of special note are the following attributes:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>os-vol-host-attr:host</literal> - the
|
|
volume's current backend.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>os-vol-mig-status-attr:migstat</literal>
|
|
- the status of this volume's migration ('None'
|
|
means that a migration is not currently in
|
|
progress).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>os-vol-mig-status-attr:name_id</literal>
|
|
- the volume ID that this volume's name on the backend
|
|
is based on. Before a volume is ever migrated, its
|
|
name on the backend storage may be based on the
|
|
volume's ID (see the volume_name_template
|
|
configuration parameter). For example, if
|
|
volume_name_template is kept at the default value
|
|
(volume-%s), then our first LVM backend will have a
|
|
logical volume named
|
|
<literal>volume-6088f80a-f116-4331-ad48-9afb0dfb196c</literal>.
|
|
During the course of a migration, if we create a new
|
|
volume and copy the data over, we will remain with
|
|
the original volume's ID, but with the new volume's
|
|
name. This is exposed by the
|
|
<literal>name_id</literal> attribute.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Now we will migrate this volume to the second LVM backend:
|
|
<screen><prompt>$</prompt> <userinput>cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c server2@lvmstorage-2</userinput></screen>
|
|
</para>
|
|
<para>We can use the <command>cinder show</command> command to see
|
|
the status of the migration. While migrating, the
|
|
<literal>migstat</literal> attribute will show states such as
|
|
<literal>migrating</literal> or <literal>completing</literal>. On
|
|
error, <literal>migstat</literal> will be set to <literal>None</literal>
|
|
and the <literal>host</literal> attribute will show the original host.
|
|
On success, in our example, the output would look like:</para>
|
|
<screen><computeroutput>+--------------------------------+--------------------------------------+
|
|
| 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 |
|
|
+--------------------------------+--------------------------------------+
|
|
</computeroutput></screen>
|
|
<para>Note that <literal>migstat</literal> is None,
|
|
<literal>host</literal> is the new host, and
|
|
<literal>name_id</literal> holds the ID of the volume
|
|
created by the migration. If we were to look at the second
|
|
LVM backend, we would find the logical volume
|
|
<literal>volume-133d1f56-9ffc-4f57-8798-d5217d851862</literal>.</para>
|
|
<note>
|
|
<para>The migration will not be visible to non-admin
|
|
users (for example, via the volume's
|
|
<literal>status</literal>). However, some operations
|
|
are not be allowed while a migration is taking place,
|
|
such as attaching/detaching a volume and deleting a
|
|
volume. If a user performs such an action during a
|
|
migration, an error will be returned.</para>
|
|
</note>
|
|
<note>
|
|
<para>Migrating volumes that have snapshots is currently
|
|
not allowed.</para>
|
|
</note>
|
|
</section>
|