Boot From Volume¶

Storage Interface¶

You will need to specify what storage interface the node will use to handle storage operations. For example, to set the storage interface to cinder on an existing node:

openstack --os-baremetal-api-version 1.33 baremetal node set \
          --storage-interface cinder $NODE_UUID

A default storage interface can be specified in ironic.conf. See the Conductor Configuration section for details.

iSCSI Configuration¶

In order for a bare metal node to boot from an iSCSI volume, the iscsi_boot capability for the node must be set to True. For example, if you want to update an existing node to boot from volume:

openstack --os-baremetal-api-version 1.33 baremetal node set \
          --property capabilities=iscsi_boot:True $NODE_UUID

You will also need to create a volume connector for the node, so the storage interface will know how to communicate with the node for storage operation. In the case of iSCSI, you will need to provide an iSCSI Qualifying Name (IQN) 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

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

Use Without Cinder¶

In the Rocky release, an external storage interface is available that can be utilized without a Block Storage Service installation.

Under normal circumstances the cinder storage interface interacts with the Block Storage Service to orchestrate and manage attachment and detachment of volumes from the underlying block service system.

The external storage interface contains the logic to allow the Bare Metal service to determine if the Bare Metal node has been requested with a remote storage volume for booting. This is in contrast to the default noop storage interface which does not contain logic to determine if the node should or could boot from a remote volume.

It must be noted that minimal configuration or value validation occurs with the external storage interface. The cinder storage interface contains more extensive validation, that is likely un-necessary in a external scenario.

Setting the external storage interface:

openstack baremetal node set --storage-interface external $NODE_UUID

Setting a volume:

openstack baremetal volume target create --node $NODE_UUID \
    --type iscsi --boot-index 0 --volume-id $VOLUME_UUID \
    --property target_iqn="iqn.2010-10.com.example:vol-X" \
    --property target_lun="0" \
    --property target_portal="192.168.0.123:3260" \
    --property auth_method="CHAP" \
    --property auth_username="ABC" \
    --property auth_password="XYZ" \

Ensure that no image_source is defined:

openstack baremetal node unset \
    --instance-info image_source $NODE_UUID

Deploy the node:

openstack baremetal node deploy $NODE_UUID

Upon deploy, the boot interface for the baremetal node will attempt to either create iPXE configuration OR set boot parameters out-of-band via the management controller. Such action is boot interface specific and may not support all forms of volume target configuration. As of the Rocky release, the bare metal service does not support writing an Operating System image to a remote boot from volume target, so that also must be ensured by the user in advance.

Records of volume targets are removed upon the node being undeployed, and as such are not presistent across deployments.

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.