Currently, Cinder only allows a volume to be attached to a single host or instance. There are times when a user may want to be able to attach the same volume to multiple instances.
Currently, Cinder only allows a volume to be attached to one instance and or host at a time. Nova makes an assumption in a number of places that assumes the limitation of a single volume to a single instance.
Allow users to share volumes between multiple guests using either read-write or read-only attachments. Clustered applications with two nodes where one is active and one is passive. Both require access to the same volume although only one accesses actively. When the active one goes down, the passive one can take over quickly and has access to the data.
To enable the ability to attach a volume to multiple hosts or instances, first we need a new volume_attachment table that tracks each attachment for cinder volumes. We will migrate the existing columns from the volume table (attached_host, instance_uuid, mountpoint, attach_time, attach_mode). The volume_attachment table will have an id (known as the attachment_id) that tracks individual attachment records for each volume. The existing cinder volume object that is returned in the API calls has a list of attachments. This attachment list will now also contain the attachment_id for each of the attachments.
That attachment_id is what nova will pass into cinder during detach API calls, so that cinder knows which attachment to detach. The cinder API will support a default attachment_id of None, which will try to do a detach if there is only a single attachment.
If cinder doesn’t get the attachment_id, and the volume only has 1 attachment, then the detach will work. If the volume has more than one attachment, then cinder will return an error saying that the volume has more than one attachment and needs the attachment_id.
The volume table will be updated to include a new column called ‘multiattach’, which is a boolean flag to signal cinder that the volume can/can’t be attached more than once. The cinder API and cinderclient will be updated to support setting the multiattach flag at volume attach time. We can add support to updating a volume record to enable the multiattach flag as well, or as a follow up patch.
The only alternative is for a user to clone a volume and attach the clone to the second instance. The downside to this is that any changes to the original volume don’t show up in the mounted clone.
The volume table will be modified to remove certain columns as they will be migrated to the new volume_attachments table.
A new volume_attachments table will be created to track all of the attachments for volumes.
Any existing attachments will be migrated to the new schema.
The REST API will be changed in 2 ways.
When listing volumes, the multiattach flag will be shown from the command line client.
Also, the command line client will include an optional –allow-multiattach to cinder create. By default multiattach is False
A possible performance hit is the extra fetches to that volume_attachment table at volume fetch time. This is a simple foreign key table join, which is indexed.
Volume driver developers should ensure that they have their volumes attached to more than one instance. We should do a follow up patch on drivers to add a ‘multiattach’ capability being reported. We could update the scheduler to filter out backends that can’t do multiattach.
There will need to be new tempest tests in place to gate on multiattach. That work is going on now as well. https://review.openstack.org/#/c/153038/
Documentation should be updated to reflect the new API changes as well as the new –allow-multiattach flag at volume create time.