3.9. Migrating a volume between back ends
You can migrate volumes between back ends within, and across, availability zones (AZs).
In highly customized deployments or in situations in which you must retire a storage system, an administrator can migrate volumes. In both use cases, multiple storage systems either share the same volume_backend_name property, or this property is undefined.
- Limitations for migrated volumes
- The volume cannot be replicated.
- The destination back end must be different from the current back end of the volume.
The existing volume type must be valid for the new back end, which means that the following must be true:
-
The volume type must either not have the
volume_backend_namedefined, or both Block Storage back ends must be configured with the samevolume_backend_name. - Both back ends must support the same features configured in the volume type, such as support for thin provisioning, support for thick provisioning, or other feature configurations.
-
The volume type must either not have the
Moving volumes from one back end to another might require extensive time and resources. For more information, see Restrictions and performance constraints when moving volumes.
Prerequisites
- You must be a project administrator to migrate volumes.
Procedure
Access the remote shell for the
openstackclientpod from your workstation:$ oc rsh -n openstack openstackclientRetrieve the name of the destination back end.
$ openstack volume backend pool listThis lists the destination back-end names, which use this syntax:
host@volume_backend_name#pool. For example:+--------------------------------+ | Name | +--------------------------------+ | cinder-volume-lvm-0@lvm#lvm | | cinder-volume-lvm2-0@lvm2#lvm2 | +--------------------------------+Migrate a volume from one back end to another.
$ openstack volume migrate --host <new_back_end_host> <volume>-
Replace
<volume>with the volume ID or name of the originating back end. -
Replace
<new_back_end_host>with the host of the destination back end.
-
Replace
Exit the
openstackclientpod:$ exit
Red Hat supports moving volumes between back ends within and across availability zones (AZs), with the following restrictions:
-
Volumes must have either have a status of
availableorin-useto be moved. -
Support for
in-usevolumes is driver dependent. - Volumes cannot have snapshots.
- Volumes cannot belong to a group.
3.9.1.1. Moving available volumes
You can move available volumes between all back ends, but performance depends on the back ends that you use.
- Assisted migration
- Many back ends support assisted migration. With assisted migration, the back end optimizes the movement of the data from the source back end to the destination back end, but both back ends must be from the same vendor. Red Hat supports back-end assisted migrations only with multi-pool back ends or when you use the cinder migrate operation for single-pool back ends, such as RBD. For more information about back-end support for assisted migration, contact the vendor.
- Generic migration
- When assisted migrations between back ends are not possible, the Block Storage service performs a generic volume migration. Generic volume migration requires volumes on both back ends to be connected before the Block Storage service moves data from the source volume to the Controller node and from the Controller node to the destination volume. The Block Storage service seamlessly performs the process regardless of the type of storage from the source and destination back ends. Ensure that you have adequate bandwidth before you perform a generic volume migration. The duration of a generic volume migration is directly proportional to the size of the volume, which makes the operation slower than assisted migration.
3.9.1.2. Moving in-use volumes
There is no optimized or assisted option for moving in-use volumes. When you move in-use volumes, the Compute service (nova) must use the hypervisor to transfer data from a volume in the source back end to a volume in the destination back end. This requires coordination with the hypervisor that runs the instance where the volume is in use.
The Block Storage service and the Compute service work together to perform this operation. The Compute service manages most of the work, because the data is copied from one volume to another through the Compute node.
Moving in-use volumes has the following restrictions:
- In-use multi-attach volumes cannot be moved while they are attached to more than one nova instance.
- Non block devices are not supported, which limits storage protocols on the target back end to be iSCSI, Fibre Channel (FC), RBD, and NVMe/TCP.
-
Ensure that you have adequate bandwidth before you move
in-usevolumes. The duration of this operation is directly proportional to the size of the volume, which makes the operation slower than assisted migration.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}