Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 2. Performing operations with the Block Storage service (cinder)

You can perform various volume operations with the Block Storage service (cinder) to manage persistent storage for your cloud instances. These operations include creating and deleting volumes, modifying volume properties like size and type, transferring ownership between users, and controlling access permissions. You can also work with volume snapshots to preserve point-in-time states, revert volumes to previous states, or clone new volumes from existing snapshots, providing flexibility for backup and recovery scenarios.

Note

All of these operations use the CLI which is faster, requires less setup, and provides more options than the Dashboard.

2.1. Prerequisites
Copiar enlace

  • 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 $ 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.2. Creating Block Storage service persistent volumes
Copiar enlace

You can create volumes to provide persistent storage for instances that you launch with the Compute service (nova). Persistent volumes preserve data even when instances are terminated, making them essential for workloads that require data retention. For encrypted volumes, you must select a volume type configured for encryption and ensure both the Compute and Block Storage services share the same static key.

Considerations
  • Volume creation limits: 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.
  • Encrypted volume size from unencrypted image: 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.
  • New volume from encrypted snapshot: 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.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Create a volume. 

    $ 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>

    • 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.
      • 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.
      • 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: 

      $ 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     |
+---------------------+--------------------------------------+

  1. Exit the openstackclient pod: 

    $ exit

2.2.1. Volume allocation on multiple back ends
Copiar enlace

Volume types specify settings and optionally a storage back end. For large deployments, the Block Storage scheduler selects the best back end for a volume, based on configured scheduler filters instead of volume type specifications.

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.3. Editing Block Storage service volume properties
Copiar enlace

You can modify volume properties after you create a volume to adapt volumes to changing requirements without recreating them. Editable properties include the volume name, description, volume type, bootable status, and access permissions.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Edit a volume. 

    $ openstack volume set \
[--name <name>] \
[--description <description>] \
[--type <new_volume_type_name>] \
[--bootable | --non-bootable] \
[--read-only | --read-write] \
<volume_name>
    • 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.

  3. 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: 

    $ openstack volume show <latest_volume_name>

  4. Exit the openstackclient pod: 

    $ exit

2.4. Resizing and extending a Block Storage volume
Copiar enlace

You can resize volumes to increase their storage capacity when your data storage needs grow beyond the original volume size. Resize volumes to expand storage without migrating data to a new volume, minimizing downtime and complexity. Note that you can only increase volume size; reducing volume size is not supported.

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

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Increase the size of the volume: 

    $ openstack volume set --size <size> <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.

  3. 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: 

    $ openstack volume show <volume>

  4. Exit the openstackclient pod: 

    $ exit

2.5. Transferring Block Storage volume ownership
Copiar enlace

You can transfer ownership of a volume to another user by creating a volume transfer request that contains a unique ID and authorization key. The recipient user logs in and uses the provided transfer credentials to claim ownership of the volume.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Create a volume transfer request: 

    $ openstack volume transfer request create [--name <name>] <volume>
    • Optional: Replace <name> with a 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.

      Example output: 

      +------------+--------------------------------------+
| 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 |
+------------+--------------------------------------+----
    • Store the transfer id or name and auth_key to share with the user so they can accept the volume transfer. You must save the transfer ID when you create the transfer because you cannot obtain the auth_key from the service again later. If you do not have the auth_key to share with another user later, you must delete the transfer and start the process again.

  3. Exit the openstackclient pod: 

    $ exit

  4. Share the transfer id and auth_key with the user who accepts the volume transfer.

    • The user accepts the volume transfer by using the following command. In this example, 6163f5d4-e4f0-4d4f-a7e9-c8e0668f934b is the volume transfer ID and bb39cacfe626da60 is the authorization key:

      Example: 

      $ 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 |
+-----------+--------------------------------------+

2.6. Retyping a Block Storage service volume
Copiar enlace

You can change a volume’s type to adjust the volume settings and capabilities applied to it. Retype volumes to upgrade or downgrade performance levels, enable additional features like backup functionality, or move volumes between different storage back ends. The volume types available for retyping depend on those configured by your administrator.

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

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Change the volume type of a volume. 

    $ openstack volume set --type <new_volume_type_name> <volume_id>
    • 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_id> 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.

  3. If the retype operation requires moving the volume between pools in a Block Storage service back end or moving a volume from one Block Storage service back end to another Block Storage service back end, apply the --retype-policy on-demand option: 

    $ openstack volume set --type <new_volume_type_name> --retype-policy on-demand <volume_id>

  4. Exit the openstackclient pod: 

    $ exit

  5. Exit the openstackclient pod: 

    $ exit

2.7. Configuring the access rights to a volume
Copiar enlace

You can configure volume access rights to control whether data can be modified on a volume. By default, volumes are set to read-write access, but you can change them to read-only to protect data from accidental modification or deletion. You can revert read-only volumes back to read-write access when write operations are needed again.

Prerequisites

  • If the volume is already attached to an instance it must be detached from the instance.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Set the required access rights of a volume: 

    $ openstack volume set [--read-only|--read-write] <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.
  3. If you detached this volume from an instance to change the access rights, then re-attach the volume.

  4. Exit the openstackclient pod: 

    $ exit

2.8. Deleting a Block Storage service volume
Copiar enlace

Delete volumes that you no longer need to free up storage resources and avoid exceeding your project’s volume quota limit. Staying within quota limits ensures that you can create new volumes when needed. Deleting unused volumes helps optimize resource allocation.

Note

You normally cannot delete a volume if it has existing snapshots, unless you use the --purge option.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Delete a volume. 

    $ openstack volume delete \
[--force | --purge] \
<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.

  3. 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: 

    $ openstack volume list

  4. Exit the openstackclient pod: 

    $ exit

2.9. Creating Block Storage service volume snapshots
Copiar enlace

You can create volume snapshots to preserve the state of a volume at a specific point in time. Snapshots are useful for creating backups before making changes, cloning volumes with existing data, or restoring volumes to a previous state if problems occur. For in-use volumes, you must use the --force option to create crash-consistent snapshots.

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

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Create a volume snapshot. 

    $ openstack volume snapshot create \
 --volume <volume> \
 [--description <description>] \
 [--force] \
 <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: 

      +-------------+--------------------------------------+
| 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 |
+-------------+--------------------------------------+

  3. Exit the openstackclient pod: 

    $ exit

2.10. Reverting a volume to the latest snapshot
Copiar enlace

You can revert a volume to the state of its most recent snapshot by modifying the existing volume rather than creating a new volume from the snapshot. This approach is faster and more efficient when you need to undo recent changes or recover from errors. Block storage drivers that support the revert-to-snapshot feature preserve copy-on-write optimizations and perform the reversion more efficiently.

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.

For information about which features your drivers support, contact your driver vendors.

Prerequisites

  • Block Storage service (cinder) REST API microversion 3.40 or later.
  • You must have created at least one snapshot for the volume.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Detach your volume: 

    $ nova volume-detach <instance_id> <vol_id>
    • Replace <instance_id> with the instance ID.
    • Replace <vol_id> with the volume ID that you want to revert.

  3. Locate the ID or name of the latest snapshot. 

    $ openstack volume snapshot-list

  4. Revert the snapshot: 

    $ openstack volume --os-volume-api-version=3.40 revert <snapshot_id_name>
    • Replace <snapshot_id_name> with the ID or the name of the snapshot.

  5. Optional: You can check that the volume you are reverting is in a reverting state: 

    $ openstack volume snapshot-list

  6. Reattach the volume: 

    $ nova volume-attach <instance_id> <vol_id>

  7. Optional: You can use the following command to verify that the volume you reverted is now in an available state. 

    $ openstack volume list

  8. Exit the openstackclient pod: 

    $ exit

2.11. Deleting Block Storage service volume snapshots
Copiar enlace

You can delete volume snapshots that you no longer need to free up storage space and avoid exceeding your project’s snapshot quota limit. Removing unused snapshots helps you stay within quota limits and maintain capacity for creating new snapshots.

Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 uses the RBD CloneV2 API. When you use Red Hat Ceph Storage as a back end, you can delete volume snapshots even if they have dependencies. If you use an external Ceph Storage back end, you must configure the minimum client on the Ceph Storage cluster. For more information, see Enabling deferred deletion for volumes or images with dependencies.

Prerequisites

  • A volume snapshot that you want to delete.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation: 

    $ oc rsh -n openstack openstackclient

  2. Delete the volume snapshot. 

    $ openstack volume snapshot delete \
 [--force] \
 <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.

  3. 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: 

    $ openstack volume snapshot list

  1. Exit the openstackclient pod: 

    $ exit
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba