From 26d7be52d76e79bd7eb218ded64244b1fc2a612e Mon Sep 17 00:00:00 2001 From: Julia Kreger Date: Thu, 7 Dec 2017 17:34:28 -0500 Subject: [PATCH] Add documentation covering storage multi-attach Change-Id: Ia4767328023acfa43ce513396fc963e75ba60b52 Closes-Bug: #1735474 --- doc/source/admin/boot-from-volume.rst | 47 +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/doc/source/admin/boot-from-volume.rst b/doc/source/admin/boot-from-volume.rst index 45ac2b0ea3..da875cf255 100644 --- a/doc/source/admin/boot-from-volume.rst +++ b/doc/source/admin/boot-from-volume.rst @@ -68,3 +68,50 @@ that is unique to your SAN. For example, to create a volume connector for iSCSI: openstack --os-baremetal-api-version 1.33 baremetal volume connector create \ --node $NODE_UUID --type iqn --connector-id iqn.2017-08.org.openstack.$NODE_UUID + +Advanced Topics +=============== + +Use without the Compute Service +------------------------------- + +As discussed in other sections, the Bare Metal service has a concept of a +`connector` that is used to represent an interface that is intended to +be utilized to attach the remote volume. + +In addition to the connectors, we have a concept of a `target` that can be +defined via the API. While a user of this feature through the Compute +service would automatically have a new target record created for them, +it is not explicitly required, and can be performed manually. + +A target record can be created using a command similar to the example below:: + + openstack --os-baremetal-api-version 1.33 baremetal volume target create \ + --node $NODE_UUID --type iscsi --boot-index 0 --volume $VOLUME_UUID + +.. Note:: A ``boot-index`` value of ``0`` represents the boot volume for a + node. As the ``boot-index`` is per-node in sequential order, + only one boot volume is permitted for each node. + +Cinder Multi-attach +------------------- + +Volume multi-attach is a function that is commonly performed in computing +clusters where dedicated storage subsystems are utilized. For some time now, +the Block Storage service has supported the concept of multi-attach. +However, the Compute service, as of the Pike release, does not yet have +support to leverage multi-attach. Concurrently, multi-attach requires the +backend volume driver running as part of the Block Storage service to +contain support for multi-attach volumes. + +When support for storage interfaces was added to the Bare Metal service, +specifically for the ``cinder`` storage interface, the concept of volume +multi-attach was accounted for, however has not been fully tested, +and is unlikely to be fully tested until there is Compute service integration +as well as volume driver support. + +The data model for storage of volume targets in the Bare Metal service +has no constraints on the same target volume from being utilized. +When interacting with the Block Storage service, the Bare Metal service +will prevent the use of volumes that are being reported as ``in-use`` +if they do not explicitly support multi-attach.