Attaching Volumes

The following sequence diagram outlines the current flow when attaching a volume to an instance using the os-volume_attachments API. This diagram uses the libvirt driver as an example virt driver to additionally document the optional interactions with the os-brick library on the compute hosts during the request.


os-brick is not always used to connect volumes to the host, most notably when connecting an instance natively to ceph rbd volumes

The diagram also outlines the various locks taken on the compute during the attach volume flow. In this example these include locks against the instance.uuid, cinder_backend.uuid orchestrated for nova-compute by os-brick and the generic connect_volume lock taken within os-brick itself. This final connect_volume lock also being held when detaching and disconnecting a volume from the host by os-brick.

blockdiag user nova-api nova-conductor nova-compute libvirt-driver os-brick cinder-api POST /servers/{server_id}/os-volume_attachments RPC call reserve_block_device_name instance.uuid lock bdm.create return BlockDeviceMapping get_device_name_for_instance Return get_device_name_for_instance Return reserve_block_device_name POST /v3/{project_id}/attachments Return HTTP 200 (without connection_info) RPC cast attach_volume Return HTTP 200 (includes device_name) instance.uuid lock cinder_backend.uuid lock PUT /v3/{project_id}/attachments/{attachment_id} Return HTTP 200 (includes connection_info) attach_volume connect_volume connect_volume lock guest.attach_device _build_device_metadata Return attach_volume POST /v3/{project_id}/attachments/{attachment_id}/action (os-complete) Return HTTP 200