diff --git a/doc/admin-guide-cloud/section_volume-migration.xml b/doc/admin-guide-cloud/section_volume-migration.xml
index 7b87bb12f0..d2ae99bb2d 100644
--- a/doc/admin-guide-cloud/section_volume-migration.xml
+++ b/doc/admin-guide-cloud/section_volume-migration.xml
@@ -25,13 +25,15 @@
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
+
+ While most back-ends support this function, not all do.
+ See the driver documentation in the OpenStack Configuration
- Reference for more
- details.
+ Reference for more
+ details.
+
If the volume is attached to a VM instance, the
@@ -45,7 +47,7 @@
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
+ #cinder-manage host listserver1@lvmstorage-1 zone1
server2@lvmstorage-2 zone1Next, as the admin user, you can see the current status of
@@ -80,19 +82,19 @@ server2@lvmstorage-2 zone1os-vol-mig-status-attr:migstat -
- the status of this volume's migration ('None' means
- that a migration is not currently in progress).
+ 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 the volume_name_template
+ volume's ID (see the
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
+ is kept as the default
+ value (volume-%s), your first LVM back-end
+ has a logical 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 get the new name but keeps its