We propose to add a volume migration feature to OpenStack - allowing for a volume to be transferred to a location and/or have its type changed. The following use cases will clarify the intent:
1. An administrator wants to bring down a physical storage device for maintenance without interfering with workloads. The admin can first migrate the volumes to other back-ends, which would result in moving volume data to the other back-ends. 2. An administrator would like to modify the properties of a volumes (volume_type). In this use case, the back-end that stores the volume supports the new volume type, and so the driver may choose to make the change internally, without moving data to another back-end. 3. Same as case #2, but where the current back-end does not support the new volume type. In this case, the data will be moved to a back-end that does support the new type, in a manner similar to case #1. 4. A Cinder component (be it the scheduler or a new service) may optimize volume placement for improved performance, availability, resiliency, or cost.
The goal is for the migration to be as transparent as possible to users and workloads - it should work for both attached and detached volumes, as well as (possibly) attaching/detaching mid-operation.
Volume migration will be enabled for all back-ends (for example, by using a generic copy function for detached volumes, and QEMU's live block copy feature for attached volumes). In addition the API will allow for storage back-ends to implement optimizations depending on source and target support (for example, using the storage controllers' remote mirroring function); this will require additions to the driver interface to report on the capabilities of the storage (based upon existing mechanisms) and to invoke storage functions.