Chapter 2. Performing operations with the Block Storage service (cinder) You can use the Block Storage volume service to perform the following volume operations: creating volumes, editing volumes, resizing volumes, changing the volume owner, changing the volume type, setting the access rights of a volume, and deleting volumes. You can also create volume snapshots to preserve the state of a volume at a specific point in time, which you can either revert to the latest state later or clone new volumes from, or delete. Note All of these operations use the CLI which is faster, requires less setup, and provides more options than the Dashboard. Prerequisites You have the oc command line tool installed on your workstation. You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges. To use Block Storage service cinder CLI commands, source the cloudrc file with the command USD source ./cloudrc before using them. If the cloudrc file does not exist, then you need to create it. For more information, see Creating the cloudrc file . 2.1. Creating Block Storage volumes Create volumes to provide persistent storage for instances that you launch with the Compute service (nova). To create an encrypted volume, you must select a volume type that is specifically configured for volume encryption. Then you must configure both the Compute and Block Storage services to use the same static key. Important By default, the maximum number of volumes you can create for a project is 10. However, the project administrator can change this limit for your project. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Create a volume. Replace <size> with the size of this volume, in gigabytes. Note The <size> argument is not required when you use --snapshot <snapshot> or --source <volume> to provide the volume source. Optional: Replace <volume_type> with the required volume type for this volume that potentially specifies the required back end and performance level. You can list the available volume types by running this command openstack volume type list . If this is not specified, then a default volume type is used. You can always change the volume type later. For more information, see Retyping volumes . If you do not specify a back end, the Block Storage scheduler will try to select a suitable back end for you. For more information, see Volume allocation on multiple back ends . Note If no suitable back end is found then the volume will not be created. Optional: Choose one of the following options to specify the volume source: No source, creates an empty volume, which does not contain a file system or partition table. Replace <image> with the image that you want to use. You can list the available images by using the openstack image list command. Note If you want to create an encrypted volume from an unencrypted image, you must ensure that the volume size is larger than the image size so that the encryption data does not truncate the volume data. Replace <snapshot> with the name of the volume snapshot that you want to clone. You can list the available snapshots by using the openstack volume snapshot list command. If you want to revert a volume to the state of its latest snapshot, then you can do this on the volume itself without having to create a new volume. For more information, see Reverting a volume to the latest snapshot . Important If you want to create a new volume from a snapshot of an encrypted volume, ensure that the new volume is at least 1GB larger than the old volume. Replace <volume> with the name of the existing volume that you want to clone. You can list the available volumes by using the openstack volume list command. Optional: Replace <availability_zone> with the availability zone of this volume. Availability zones or logical server groups, along with host aggregates, are a common method for segregating resources within OpenStack. For more information about availability zones and host aggregates, see Creating and managing host aggregates in Configuring the Compute service for instance creation . Optional: Replace <description> with a concise description of this volume, enclosed in double quotes (") when this contains spaces. Optional: Determine whether this volume is bootable or not. The default state of a volume is --non-bootable . A --bootable volume should contain the files needed to initiate the operating system. This setting is usually used when the volume is created from a bootable image. Optional: Determine the access permissions of this volume. The default state of a volume is --read-write to allow data to be written to and read from it. You can mark a volume as --read-only to protect its data from being accidentally overwritten or deleted. Volumes that have been set as read-only can be changed to read-write. Replace <volume_name> with the name of this volume. For example: Exit the openstackclient pod: USD exit 2.1.1. Volume allocation on multiple back ends When you create a volume, you can choose the required volume type, which specifies the volume settings that in some cases can specify the required back end. For large deployments with large numbers of back ends it is usually not necessary for volume types to specify the back ends. In this case it is better that the Block Storage scheduler determines the best back end for a volume, based on the configured scheduler filters. If you do not specify a back end when creating the volume, for example, when you select a volume type that does not specify a specific back end, then the Block Storage scheduler will try to select a suitable back end for you. The scheduler uses the following default filters to select suitable back ends: AvailabilityZoneFilter Filters out all back ends that do not meet the availability zone requirements of the requested volume. CapacityFilter Selects only back ends with enough space to accommodate the volume. CapabilitiesFilter Selects only back ends that can support any specified settings in the volume. If there is more than one suitable back end, then the scheduler uses a weighting method to pick the best back end. By default, the CapacityWeigher method is used, so that the filtered back end with the most available free space is selected. Note If there is no suitable back end then the volume will not be created. 2.2. Editing a volume You can change several properties of a volume after you have created it, such as the volume name, volume description, volume type, whether the volume is bootable, and the access permissions of this volume. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Edit a volume. Optional: Replace <name> with the new name for this volume. Optional: Replace <description> with a revised concise description of this volume, enclosed in double quotes (") when this contains spaces. Optional: Replace <new_volume_type_name> with the name of the new volume type. You can list the available volume types by using the openstack volume type list command. Optional: Determine whether this volume should be bootable or not. The default state of a volume is --non-bootable . A --bootable volume should contain the files needed to initiate the operating system. Optional: Determine the access permissions of this volume. The default state of a volume is --read-write to allow data to be written to and read from it. You can mark a volume as --read-only to protect its data from being accidentally overwritten or deleted. Volumes that have been set as read-only can be set back to read-write. Replace <volume_name> with the existing volume name or ID. You can list the available volumes by using the openstack volume list command. You can determine which volumes use which volume types by using the `openstack volume show`command for each volume. Optional: This command does not provide any confirmation that the changes to the volume were successful. You can run the following command to review the changes made to this volume. If you have changed the volume name then replace <latest_volume_name> with this new name, otherwise use the existing volume name: Exit the openstackclient pod: USD exit 2.3. Resizing (extending) a volume Resize volumes to increase the storage capacity of the volumes, you cannot reduce the size of the volume. Note The ability to resize a volume in use is supported but it is driver dependent. Red Hat Ceph Storage is supported. You cannot extend in-use multi-attach volumes. For more information about support for this feature, contact Red Hat Support . Procedure Access the remote shell for the OpenStackClient pod from your workstation: Increase the size of the volume: Replace <size> with the required size of this volume, in gigabytes. Replace <volume> with the name or ID of the volume you want to extend. You can list the available volumes by using the openstack volume list command. Optional: This command does not provide any confirmation that volume has been successfully resized. You can run the following command to review the changes made to this volume: Exit the openstackclient pod: USD exit 2.4. Changing the volume owner You must complete the following two steps to change the user who owns a volume: A volume transfer is initiated by the volume's owner, who clears the ownership of the volume and generates the id , name , and auth_key values. Important You must save the auth_key and the id or name values of this transfer request and send them to the new user, because this is the ONLY time that the auth_key is generated for security purposes. The new user can claim ownership of the volume, by logging in and using the values that he has received to accept the transfer. Initiate the transfer of volume ownership Access the remote shell for the OpenStackClient pod from your workstation: The current owner of the volume must log in from the command line: This user creates a volume transfer request. Optional: Replace <name> with a literal name to identify this transfer request in addition to the ID. If you do not do this then the name is None . Replace <volume> with the name or ID of the volume that you want to transfer the ownership of. You can list the available volumes by using the openstack volume list command. This command clears the ownership of the volume and creates a table of the id , name , and auth_key values for the transfer request. These values can be given to, and used by, another user to accept the transfer request and become the new owner of the volume. For example: Important Ensure that you save the value of the auth_key and the id or name , if specified, and send them to the user who will become the new volume owner because NONE of the other openstack volume transfer request commands provide the auth_key for security purposes. Exit the openstackclient pod: USD exit Complete the transfer of volume ownership Access the remote shell for the OpenStackClient pod from your workstation: The new user must log in from the command line. This user accepts the volume transfer request. Replace <transfer_request> with the id or name that you have received from the original volume owner who created the volume transfer request. Replace <auth_key> with the auth_key value that you have received from the original volume owner who created the volume transfer request. For example: Exit the openstackclient pod: USD exit 2.5. Retyping a volume You can retype or change the volume type of a volume to adjust the settings applied to this volume, for a variety of reasons, such as: To upgrade or downgrade the performance of this volume. To facilitate additional functionality, such as the ability to back up this volume. To move a volume from one backend to another. In this case, you need at least two volume types that each target different backends and may have specifications that are backend specific. Therefore, by retyping a volume, the volume is moved to a different back end. For more information, see Restrictions and performance constraints when moving volumes in Customizing persistent storage . Your available options when retyping a volume depend upon the volume types that your administrator has created. Important You cannot retype an unencrypted volume to an encrypted volume of the same size. Encrypted volumes require additional space to store the encryption data. Prerequisites Only volume owners and administrators can retype volumes. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Change the volume type of a volume. Replace <new_volume_type_name> with the name of the new volume type. You can list the available volume types by using the openstack volume type list command. Replace <volume> with the name or ID of the volume. You can list the available volumes by using the openstack volume list command. You can determine which volumes use which volume types by using the `openstack volume show`command for each volume. Exit the openstackclient pod: USD exit 2.6. Configuring the access rights to a volume The default state of a volume is read-write to allow data to be written to and read from it. You can mark a volume as read-only to protect its data from being accidentally overwritten or deleted. Volumes that have been set as read-only can be set back to read-write. Prerequisites If the volume is already attached to an instance it must be detached from the instance. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Set the required access rights of a volume: Choose --read-only or --read-write to set the required volume access. Replace <volume> with the name or ID of the required volume. You can list the available volumes by using the openstack volume list command. If you detached this volume from an instance to change the access rights, then re-attach the volume. Exit the openstackclient pod: USD exit 2.7. Deleting a volume You should delete the volumes that you no longer need, to ensure that you will not exceed the volume quota limit for your project, which will prevent you from creating more volumes. Note You normally cannot delete a volume if it has existing snapshots, unless you use the --purge option. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Delete a volume. Optional: Either choose the --force option when deleting a volume, to override any normal volume checks such as whether the volume is in use or not. Or choose the --purge option when deleting a volume, to also delete any snapshots that have been created for this volume. Replace <volume> with the name or ID of the volume that you want to remove. You can list the available volumes by using the openstack volume list command. Warning There is not undo action that is possible after using this command, so be sure that you are deleting the required volume. Optional: This command does not provide any confirmation that the volume has been deleted successfully. You can run the following command to list the available volumes and you should not see the volume that you have deleted: Exit the openstackclient pod: USD exit 2.8. Creating volume snapshots You can preserve the state of a volume at a specific point in time by creating a volume snapshot. When you want to create snapshots of in use volumes, which are crash consistent but not application consistent, use the --force option. When you use a Block Storage (cinder) REST API microversion of 3.66 or later, this is the default action. You can then use the snapshot to clone new volumes or to revert the state of the volume to. For more information about creating a new volume from a snapshot, see Creating Block Storage volumes . Important By default, the maximum number of snapshots you can create for a project is 10. However, the project administrator can change this limit for your project. Volume backups are different from snapshots. Backups preserve the data contained in the volume, whereas snapshots preserve the state of a volume at a specific point in time. You cannot delete a volume if it has existing snapshots. Volume backups prevent data loss, whereas snapshots facilitate cloning. For this reason, snapshot back ends are typically colocated with volume back ends to minimize latency during cloning. By contrast, a backup repository is usually located in a different location, for example, on a different node, physical storage, or even geographical location in a typical enterprise deployment. This is to protect the backup repository from any damage that might occur to the volume back end. Prerequisites A volume that you want to snapshot. For more information about creating volumes, see Creating Block Storage volumes . Procedure Access the remote shell for the OpenStackClient pod from your workstation: Create a volume snapshot. Replace <volume> with the name or the ID of the volume that you want to create a snapshot of. You can list the available volumes by using the openstack volume list command. Optional: Replace <description> with a concise description of this snapshot, enclosed in double quotes (") when this contains spaces. Optional: If you receive a warning that a volume is in use when creating a snapshot, you can use this --force option to ignore the warning and create the snapshot regardless. Replace <snapshot> with the name of this volume snapshot. This command provides a table containing the details of this snapshot. For example: Exit the openstackclient pod: USD exit 2.9. Reverting a volume to the latest snapshot To revert a volume to the state of its most recent snapshot you can change the state of your volume, instead of creating a new volume from this snapshot. For more information about creating a new volume from a snapshot, see Creating Block Storage volumes Block storage drivers that support the revert-to-snapshot feature, perform this task faster and more efficiently than the drivers that do not. For example, copy-on-write space optimizations are unaffected. For information about which features your drivers support, contact your driver vendors. Limitations You cannot use the revert-to-snapshot feature on an attached or in-use volume. You cannot use the revert-to-snapshot feature on a bootable root volume because it is not in the available state. To use this feature, the instance must have been booted with the delete_on_termination=false (default) property to preserve the boot volume if the instance is terminated. When you want to revert to a snapshot, you must first delete the initial instance so that the volume is available. You can then revert it and create a new instance from the volume. You cannot revert a volume that you resize (extend) after taking the snapshot. There might be limitations to using the revert-to-snapshot feature with multi-attach volumes. Check whether such limitations apply before you use this feature. Prerequisites Block Storage service (cinder) REST API microversion 3.40 or later. You must have created at least one snapshot for the volume. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Detach your volume: Replace <instance_id> with the instance ID. Replace <vol_id> with the volume ID that you want to revert. Locate the ID or name of the latest snapshot. Revert the snapshot: Replace <snapshot_id_name> with the ID or the name of the snapshot. Optional: You can check that the volume you are reverting is in a reverting state: Reattach the volume: Optional: You can use the following command to verify that the volume you reverted is now in an available state. Exit the openstackclient pod: USD exit 2.10. Deleting volume snapshots You should delete the volume snapshots that you no longer need, to ensure that you will not exceed the snapshot quota limit for your project, which will prevent you from creating more snapshots. Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 uses the RBD CloneV2 API, which allows you to delete volume snapshots even if they have dependencies, when using the Ceph as a back end. But if you use an external Ceph back end, you must also configure the minimum client on the Ceph cluster for this to work. For more information, see Enabling deferred deletion for volumes or images with dependencies Prerequisites A volume snapshot that you want to delete. Procedure Access the remote shell for the OpenStackClient pod from your workstation: Delete the volume snapshot. Optional: Choose the --force option when deleting a snapshot, to override any normal snapshot state checks. Replace <snapshot> with the name of this volume snapshot that you want to delete. You can list the available snapshots by using the openstack volume snapshot list command. Warning There is not undo action that is possible after using this command, so be sure that you are deleting the required snapshot. Optional: This command does not provide any confirmation that the snapshot has been deleted successfully. You can run the following command to list the available volumes and you should not see the snapshot that you have deleted: Exit the openstackclient pod: USD exit

Commands:
oc rsh -n openstack openstackclient
openstack volume create --size <size> [--type <volume_type>] [--image <image> | --snapshot <snapshot> | --source <volume>] [--availability-zone <availability_zone>] [--description <description>] [--bootable | --non-bootable] [--read-only | --read-write] <volume_name>
openstack volume create --size 10 --type MyEncryptedVolType --availability-zone nova --description "A blank encrypted volume" MyEncVol +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2024-11-12T06:40:21.619913 | | description | A blank encrypted volume | | encrypted | True | | id | 90fe8005-89e7-4629-858d-815b2f8a5001 | | migration_status | None | | multiattach | False | | name | MyEncVol | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | MyEncryptedVolType | | updated_at | None | | user_id | a20f9aed5757443da0e5fb7bab067f9b | +---------------------+--------------------------------------+
exit
oc rsh -n openstack openstackclient
openstack volume set [--name <name>] [--description <description>] [--type <new_volume_type_name>] [--bootable | --non-bootable] [--read-only | --read-write] <volume_name>
openstack volume show <latest_volume_name>
exit
oc rsh -n openstack openstackclient
openstack volume set -size <size> <volume>
openstack volume show <volume>
exit
oc rsh -n openstack openstackclient
openstack volume transfer request create [--name <name>] <volume>
+------------+--------------------------------------+ | Field | Value | +------------+--------------------------------------+ | auth_key | bb39cacfe626da60 | | created_at | 2024-11-12T08:30:01.826548 | | id | 6163f5d4-e4f0-4d4f-a7e9-c8e0668f934b | | name | None | | volume_id | fc13ff34-ac2a-4d26-9744-860b2b19b6ca | +------------+--------------------------------------+----
exit
oc rsh -n openstack openstackclient
openstack volume transfer request accept --auth-key <auth_key> <transfer_request>
openstack volume transfer request accept --auth-key bb39cacfe626da60 6163f5d4-e4f0-4d4f-a7e9-c8e0668f934b +-----------+--------------------------------------+ | Field | Value | +-----------+--------------------------------------+ | id | 6163f5d4-e4f0-4d4f-a7e9-c8e0668f934b | | name | None | | volume_id | fc13ff34-ac2a-4d26-9744-860b2b19b6ca | +-----------+--------------------------------------+
exit
oc rsh -n openstack openstackclient
openstack volume set --type <new_volume_type_name> <volume>
exit
oc rsh -n openstack openstackclient
openstack volume set [--read-only|--read-write] <volume>
exit
oc rsh -n openstack openstackclient
openstack volume delete [--force | --purge] <volume>
openstack volume list
exit
oc rsh -n openstack openstackclient
openstack volume snapshot create --volume <volume> [--description <description>] [--force] <snapshot>
+-------------+--------------------------------------+ | Field | Value | +-------------+--------------------------------------+ | created_at | 2024-11-12T11:22:40.533557 | | description | None | | id | 2ee2cb3d-a59a-473e-a17d-482d7abcd5d5 | | name | MyVol1snap | | properties | | | size | 12 | | status | creating | | updated_at | None | | volume_id | 99510e51-ad60-4d60-b62a-7321e6442f06 | +-------------+--------------------------------------+
exit
oc rsh -n openstack openstackclient
nova volume-detach <instance_id> <vol_id>
openstack volume snapshot-list
openstack volume --os-volume-api-version=3.40 revert <snapshot_id_name>
openstack volume snapshot-list
nova volume-attach <instance_id> <vol_id>
openstack volume list
exit
oc rsh -n openstack openstackclient
openstack volume snapshot delete [--force] <snapshot>
openstack volume snapshot list
exit