/
section_volume-migration.xml
171 lines (171 loc) · 9.97 KB
/
section_volume-migration.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
<?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 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).</para>
<para>These workflows are possible 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 might be able to perform. If the back-end is
not able to perform the migration, the Block Storage
Service uses one of two generic flows, as
follows.</para>
</listitem>
<listitem>
<para>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
driver documentation in the <link
xlink:href="http://docs.openstack.org/havana/config-reference/content/"
><citetitle>OpenStack Configuration
Reference</citetitle></link> for more
details.</para>
</listitem>
<listitem>
<para>If the volume is attached to a VM instance, the
Block Storage Service 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.</para>
</listitem>
</orderedlist>
<para>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.</para>
<para>First, list the available back-ends:</para>
<screen><prompt>$</prompt> <userinput>cinder-manage host list</userinput>
<computeroutput>server1@lvmstorage-1 zone1
server2@lvmstorage-2 zone1</computeroutput></screen>
<para>Next, as the admin user, you 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>Note these attributes:</para>
<itemizedlist>
<listitem>
<para><literal>os-vol-host-attr:host</literal> - the
volume's current back-end.</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 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 the volume_name_template
configuration parameter). For example, if
volume_name_template is kept as the default value
(volume-%s), your first LVM back-end has a logical
volume named
<literal>volume-6088f80a-f116-4331-ad48-9afb0dfb196c</literal>.
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 the <literal>name_id</literal>
attribute.</para>
</listitem>
</itemizedlist>
<note>
<para>If you plan to decommission a block storage node, you must
stop the <systemitem class="service">cinder</systemitem> volume
service on the node after performing the migration.</para>
<para os="rhel;centos;fedora;opensuse;sles">On nodes that run
CentOS, Fedora, openSUSE, RedHat Enterprise Linux, or SUSE Linux
Enterprise, run:</para>
<screen os="rhel;centos;fedora"><prompt>#</prompt> <userinput>service openstack-cinder-volume stop</userinput>
<prompt>#</prompt> <userinput>chkconfig openstack-cinder-volume off</userinput></screen>
<para os="debian;ubuntu">On nodes that run Ubuntu or Debian, run:
</para>
<screen os="debian;ubuntu"><prompt>#</prompt> <userinput>service cinder-volume stop</userinput>
<prompt>#</prompt> <userinput>chkconfig cinder-volume off</userinput></screen>
<para>Stopping the <systemitem>cinder</systemitem> volume service
will prevent volumes from being allocated to the node.</para>
</note>
<para>Migrate this volume to the second LVM back-end:</para>
<screen><prompt>$</prompt> <userinput>cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c server2@lvmstorage-2</userinput></screen>
<para>You can use the <command>cinder show</command> command to
see the status of the migration. While migrating, the
<literal>migstat</literal> attribute shows states such as
<literal>migrating</literal> or
<literal>completing</literal>. On error,
<literal>migstat</literal> is set to
<literal>None</literal> and the <literal>host</literal>
attribute shows the original host. On success, in this
example, the output looks 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 you look at the second LVM
back end, you find the logical volume
<literal>volume-133d1f56-9ffc-4f57-8798-d5217d851862</literal>.</para>
<note>
<para>The migration is not visible to non-admin users (for
example, through the volume <literal>status</literal>).
However, some operations are not 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 is returned.</para>
</note>
<note>
<para>Migrating volumes that have snapshots are currently not
allowed.</para>
</note>
</section>