Bug 1122356 - [RFE][cinder]: Generic Volume Migration
Summary: [RFE][cinder]: Generic Volume Migration
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: 8.0 (Liberty)
Assignee: Jon Bernard
QA Contact: Yogev Rabl
URL: https://blueprints.launchpad.net/cind...
Whiteboard: upstream_milestone_liberty-3 upstream...
: 1121610 1205621 (view as bug list)
Depends On: 1315661
Blocks: 1131335
TreeView+ depends on / blocked
Reported: 2014-07-23 04:06 UTC by RHOS Integration
Modified: 2019-11-14 06:28 UTC (History)
14 users (show)

Fixed In Version: openstack-cinder-7.0.0-2.el7ost, python-os-brick-0.5.0-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2016-04-07 20:59:20 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 135002 0 None ABANDONED Add support for generic volume migration 2020-08-21 01:58:15 UTC
OpenStack gerrit 187270 0 None MERGED Add support for file I/O volume migration 2020-08-21 01:58:15 UTC
Red Hat Product Errata RHEA-2016:0603 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 8 Enhancement Advisory 2016-04-08 00:53:53 UTC

Description RHOS Integration 2014-07-23 04:06:43 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/generic-volume-migration.


When migrating a volume between two backends, the copy_volume_data routine in the source volume's driver is executed to move the blocks from one volume to another.  This routine assumes that both source and destination volumes can be attached locally via iSCSI.  This is technically not necessary for local volumes and also prevents drivers such as Ceph from participating in volume migration operations.

I propose that we abstract the iSCSI volume attachement into a routine that can determine the best way to return a file-like python object.  For remote volumes, this may fall back to attaching the volume using iSCSI.  And for drivers that do not use iSCSI like Ceph, its RBD interface can be hidden behind a similar file-like object such that copy_volume_data does not see this difference.

Blueprint submission via cinder-specs is in progress.

Specification URL (additional information):


Comment 1 Sean Cohen 2015-03-18 16:02:25 UTC
*** Bug 1121610 has been marked as a duplicate of this bug. ***

Comment 2 Sean Cohen 2015-03-25 12:20:59 UTC
*** Bug 1205621 has been marked as a duplicate of this bug. ***

Comment 7 Jon Bernard 2016-01-12 02:55:34 UTC
I believe each driver validates the extra specs and can allow the migration to continue if acceptable.  If you can give me a specific example I'd be happy to verify and report back.

'migrate' will move a volume from one host to another if the volume type and backend do not change.  'retype' allows you to change type and backend if desired.  Without a migration policy, retype will update metadata (extra specs) but not move the volume data from its current location.  If not moving the data means the retype cannot be satisfied, then migration is required where the type also changes.  And this is where we connect to both backends, read data from the source, and write it to the destination.

The cinder naming is a little confusing in this regard, let me know if I can clarify any of this.

Comment 9 Jon Bernard 2016-01-13 20:51:28 UTC
I think what's there is accurate.  For retype, we are missing the case of retyping without migration where the user wants to change the class (or other attribute) of the storage.  Is that documented in another section?  If not it might be good to include it here.

Also, wether only the admin can issue these commands is dependent on the configuration, it's possible to allow users to migrate and retype their own storage volumes.

Comment 11 Jon Bernard 2016-01-15 17:08:34 UTC
This is better, I like it.  Thanks Don!

Comment 12 Yogev Rabl 2016-03-09 08:01:12 UTC
Verification failed due to Bug 1315661 
tested on 

Comment 13 Sergey Gotliv 2016-03-09 13:19:41 UTC
Probably blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1315661

Comment 18 Yogev Rabl 2016-03-15 13:03:00 UTC
Migration of volume between one pool to another on the same Ceph cluster. In future releases the feature will support migration between Ceph clusters, documented in  Bug 1315661 

The verification was on 

Comment 20 errata-xmlrpc 2016-04-07 20:59:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.