Bug 1601807

Description of problem:

Cu is trying to retype the volume beween two different backends, i.e 

VMAX -> CEPH
CEPH -> VMAX

They've urgency in handling this kind of volume retype:

However, per Engineering it is not yet supported. We need to update the section as pointed by Cu stating the same clearly, since it is leading to few confusions. 

Here is the extract of our documentation from customer mail, which they followed:
-------------------------------------------------------------------------------
"2.3.10. Changing a Volume’s Type (Volume Re-typing)

Volume re-typing is the process of applying a volume type (and, in turn, its settings) to an already

existing volume. For more information about volume types, see Section 2.2.1, “Group Volume Settings

with Volume Types”.

A volume can be re-typed whether or not it has an existing volume type. In either case, a re-type will

only be successful if the Extra Specs of the volume type can be applied to the volume. Volume retyping

is useful for applying pre-defined settings or storage attributes to an existing volume, such as

when you want to:

Migrate the volume to a different back end (Section 2.4.2.2, “Migrate Between Back Ends” ).

Change the volume’s storage class/tier.

Users with no administrative privileges can only re-type volumes they own. To perform a volume retype:

1. In the dashboard, select Project > Compute > Volumes .

2. In the Actions column of the volume to be migrated, select Change Volume Type.

3. In the Change Volume Type dialog, select the target volume type defining the new back end

from the Type drop-down list.

NOTE

If you are migrating the volume to another back end, select On Demand from

the Migration Policy drop-down list. For more information, see Section 2.4.2.2,

“Migrate Between Back Ends”.

4. Click Change Volume Type to start the migration.

 

2.4.2.2. Migrate Between Back Ends

Migrating a volume between back ends, on the other hand, involves volume re-typing. This means that

in order to migrate to a new back end:

1. The new back end must be specified as an Extra Spec in a separate target volume type.

2. All other Extra Specs defined in the target volume type must be compatible with the volume’s

original volume type.

See Section 2.2.1, “Group Volume Settings with Volume Types” and Section 2.3.2, “Specify Back End

for Volume Creation” for more details.

When defining the back end as an Extra Spec, use volume_backend_name as the Key. Its

corresponding value will be the back end’s name, as defined in the Block Storage configuration file

(/etc/cinder/cinder.conf). In this file, each back end is defined in its own section, and its corresponding

name is set in the volume_backend_name parameter.

Once you have a back end defined in a target volume type, you can migrate a volume to that back end

through re-typing. This involves re-applying the target volume type to a volume, thereby applying the

new back end settings. See Section 2.3.10, “Changing a Volume’s Type (Volume Re-typing)” for

instructions.

To do so:

1. In the dashboard, select Project > Compute > Volumes .

2. In the Actions column of the volume to be migrated, select Change Volume Type.

3. In the Change Volume Type dialog, select the target volume type defining the new back end

from the Type drop-down list.

4. Select On Demand from the Migration Policy drop-down list.

5. Click Change Volume Type to start the migration"
-------------------------------------------------------------------------------




Version-Release number of selected component (if applicable):

Red Hat OpenStack 10


Actual results:

Live migration with different backends not working

Expected results:

Live migration should work between different backends


Additional info:

We have raised a high priority RFE too, you may refer to the same, on which Engineering has provided the update:
~~~
https://bugzilla.redhat.com/show_bug.cgi?id=1598513
~~~