Attach a single volume to multiple hosts
Currently, the existing block storage (cinder) drivers allow for only a single volume to be attached to a single VM instance via iSCSI or Fibre Channel. To support a cluster, a single volume would need to be exported to multiple host. In this case vCenter will be used as an example, but any Hypervisor that supports clusters could require this functionality.
The Cinder etherpad https:/
The Cinder work is not yet determined but would require minor work in tracking that a volume has multiple host attached to it. Possibly changing the database entries for what volume is attached to a single host to a list of host. More work may be required once test have been ran to verify the data flow between multiple attach points.
This blueprint in for the limited cinder work that would be required from the following Nova blueprint: https:/
Blueprint information
- Status:
- Complete
- Approver:
- Mike Perez
- Priority:
- High
- Drafter:
- Kurt Martin
- Direction:
- Approved
- Assignee:
- Walt Boring
- Definition:
- Approved
- Series goal:
- Accepted for kilo
- Implementation:
- Implemented
- Milestone target:
- 2015.1.0
- Started by
- Kurt Martin
- Completed by
- Mike Perez
Related branches
Related bugs
Sprints
Whiteboard
https:/
Addressed by: https:/
Adding Multiple volume attaching support to Cinder. One volume can be attached several instances or hosts.
If multi-attach is determined to be extension functionality, then how to implement as an extension of the core attachment functionality? When Cinder extension framework/mechanism ready to use?
-------
The concept of a call to flag a volume as multi-attach capable (preferably at create time for those of use who do COW on the client normally, but I can hack around it if that is seen as too restrictive) seems to have vanished - this is a concept I believe we really, really need. Normal volumes should *not* be multi-attach, the opportunity for the tenant to shoot themselves in the foot is jsut too high, and the fact that attach can only happen once is baked into the current API -- DuncanT
-------
Although the concept of such an explicit choice is missing from the linked patchset, that patchset was submitted *before* it was reinforced via discussion in the Cinder meetings that such a choice was required. As such I don't believe it's been lost as much as no implementation work has been done since those discussions. We'll need to work lining up design page if we are to achieve this in Juno. -sgordon
-------
I've picked up this work and I am working on a few patches that I'll submit to nova, cinder, cinderclient as WIP prior to Atlanta. It will have the shareable flag setting at volume create time
---Walt (hemna)
-------
The Nova-spec gerrit review
https:/
The python-cinderclient review
https:/
The Nova review
https:/
The Cinder review
https:/
---Walt
-------
Gerrit topic: https:/
Addressed by: https:/
WIP Add volume multi attach support
You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.
(This is an automated message)
Gerrit topic: https:/
Addressed by: https:/
Volume multi attachments
Gerrit topic: https:/
-------
-- River Zhang-- is there any update for kilo release? this feature is not found in the kilo release notes
Addressed by: https:/
Storwize driver report capability for multiattach
Addressed by: https:/
Add the nova-multiattach job to the experimental queue
Addressed by: https:/
Add back support for the multiattach flag for volume create
Work Items
Dependency tree
* Blueprints in grey have been implemented.