Bug 1056108
| Summary: | [RFE] Volume migration | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Scott Lewis <sclewis> |
| Component: | openstack-cinder | Assignee: | Eric Harney <eharney> |
| Status: | CLOSED ERRATA | QA Contact: | Dafna Ron <dron> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.0 | CC: | breeler, dnavale, dron, eharney, mlopes, sclewis, scohen, sgordon, yeylon, yrabl |
| Target Milestone: | z3 | Keywords: | FutureFeature, Reopened, TestOnly, ZStream |
| Target Release: | 4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://blueprints.launchpad.net/cinder/+spec/volume-migration | ||
| Whiteboard: | upstream_milestone_none upstream_status_implemented upstream_definition_approved | ||
| 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).
|
Story Points: | --- |
| Clone Of: | 1045054 | Environment: | |
| Last Closed: | 2014-03-25 19:23:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 985953, 1035766, 1045054 | ||
| Bug Blocks: | 975499 | ||
|
Comment 1
Scott Lewis
2014-01-21 14:26:30 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. (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? (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? 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 |