Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056108 - [RFE] Volume migration
Summary: [RFE] Volume migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 4.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: z3
: 4.0
Assignee: Eric Harney
QA Contact: Dafna Ron
URL: https://blueprints.launchpad.net/cind...
Whiteboard: upstream_milestone_none upstream_stat...
: 1045054 (view as bug list)
Depends On: 985953 1035766 1045054
Blocks: RHOS40RFE
TreeView+ depends on / blocked
 
Reported: 2014-01-21 14:25 UTC by Scott Lewis
Modified: 2016-04-26 21:14 UTC (History)
10 users (show)

Fixed In Version: openstack-cinder-2013.2-9.el6ost
Doc Type: Enhancement
Doc Text:
In the OpenStack Block Storage service, an enhancement which allows the migration of Block Storage volume between different Block Storage backends has been added. This allows the relocation of a storage volume to a different host (or storage backend).
Clone Of: 1045054
Environment:
Last Closed: 2014-03-25 19:23:32 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0334 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform 4 Bug Fix and Enhancement Advisory 2014-03-25 23:22:45 UTC
OpenStack gerrit 33055 None None None Never
OpenStack gerrit 37685 None None None Never

Comment 1 Scott Lewis 2014-01-21 14:26:30 UTC
*** Bug 1045054 has been marked as a duplicate of this bug. ***

Comment 2 Yogev Rabl 2014-02-02 12:18:09 UTC
The functionality of this feature is lacking:

1. in the case that a volume is been create and assigned to a back end using types, a single volume cannot be migrated. The change will be in the type, thus all the volume in the type will be migrated. 

2. When not associating a volume to a beck end with a type, the back end will be chosen by the scheduler according to the amount of free space.

Comment 3 Eric Harney 2014-02-03 15:57:28 UTC
(In reply to Yogev Rabl from comment #2)
> The functionality of this feature is lacking:
> 
> 1. in the case that a volume is been create and assigned to a back end using
> types, a single volume cannot be migrated. The change will be in the type,
> thus all the volume in the type will be migrated. 
> 

Should be handled by volume retype in Icehouse.   Bug 984270

> 2. When not associating a volume to a beck end with a type, the back end
> will be chosen by the scheduler according to the amount of free space.

This sounds like the expected behavior... what else did you have in mind here?

Comment 5 Yogev Rabl 2014-03-17 06:35:43 UTC
(In reply to Eric Harney from comment #3)
> (In reply to Yogev Rabl from comment #2)
> > The functionality of this feature is lacking:
> > 
> > 1. in the case that a volume is been create and assigned to a back end using
> > types, a single volume cannot be migrated. The change will be in the type,
> > thus all the volume in the type will be migrated. 
> > 
> 
> Should be handled by volume retype in Icehouse.   Bug 984270
> 
> > 2. When not associating a volume to a beck end with a type, the back end
> > will be chosen by the scheduler according to the amount of free space.
> 
> This sounds like the expected behavior... what else did you have in mind
> here?

I'm not sure, how does the scheduler check the amount of free space, does it simply check the amount of the available space, or check the percentage of the available space in compare to the entire storage space?

Comment 12 errata-xmlrpc 2014-03-25 19:23:32 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.

http://rhn.redhat.com/errata/RHBA-2014-0334.html


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