Thursday, April 18 • 4:10pm - 4:50pm
Cinder Volume Migration

Sign up or log in to save this to your schedule and see who's attending!

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.

(Session proposed by Avishay Traeger)

Thursday April 18, 2013 4:10pm - 4:50pm

Attendees (0)