Chapter 2. Configuring the Block Storage service (cinder)

Procedure

1. Run the following command to verify whether all of the services for a cluster are running:

   $ cinder cluster-list --detailed

   Alternatively, run the cluster show command.

2. If any services are not running, run the following command to identify those specific services:

   $ cinder service-list

3. Run the following command to trigger the server cleanup:

   $ cinder work-cleanup [--cluster <cluster-name>] [--host <hostname>] [--binary <binary>] [--is-up <True|true|False|false>] [--disabled <True|true|False|false>] [--resource-id <resource-id>] [--resource-type <Volume|Snapshot>]

   Note

   Filters, such as --cluster, --host, and --binary, define what the command cleans. You can filter on cluster name, host name, type of service, and resource type, including a specific resource. If you do not apply filtering, the command attempts to clean everything that can be cleaned.

   The following example filters by cluster name:

   $ cinder work-cleanup --cluster tripleo@tripleo_ceph

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. Click Create Volume Type.
3. Enter the volume type name in the Name field.
4. Click Create Volume Type. The new type appears in the Volume Types table.
5. Select the volume type’s View Extra Specs action.
6. Click Create and specify the Key and Value. The key-value pair must be valid; otherwise, specifying the volume type during volume creation will result in an error. For instance, to specify a back end for this volume type, add the volume_backend_name Key and set the Value to the name of the required back end.
7. Click Create. The associated setting (key-value pair) now appears in the Extra Specs table.

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. In the Volume Types table, select the volume type’s View Extra Specs action.

3. On the Extra Specs table of this page, you can:

   • Add a new setting to the volume type. To do this, click Create and specify the key/value pair of the new setting you want to associate to the volume type.
   • Edit an existing setting associated with the volume type by selecting the setting’s Edit action.
   • Delete existing settings associated with the volume type by selecting the extra specs' check box and clicking Delete Extra Specs in this and the next dialog screen.

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. On the QOS Specs table, click Create QOS Spec.
3. Enter a name for the QOS Spec.

4. In the Consumer field, specify where the QOS policy should be enforced:

   Table 2.1. Consumer Types

   Type	Description
   back-end	QOS policy will be applied to the Block Storage back end.
   front-end	QOS policy will be applied to Compute.
   both	QOS policy will be applied to both Block Storage and Compute.

5. Click Create. The new QOS Spec should now appear in the QOS Specs table.
6. In the QOS Specs table, select the new spec’s Manage Specs action.

7. Click Create, and specify the Key and Value. The key-value pair must be valid; otherwise, specifying a volume type associated with this QOS Spec during volume creation will fail.

   For example, to set read limit IOPS to 500, use the following Key/Value pair:

   read_iops_sec=500

8. Click Create. The associated setting (key-value pair) now appears in the Key-Value Pairs table.

Procedure

1. As an administrator in the dashboard, select Admin > Volumes > Volume Types.
2. In the Volume Types table, select the type’s Manage QOS Spec Association action.
3. Select a QOS Spec from the QOS Spec to be associated list. To disassociate a QOS specification from an existing volume type, select None.
4. Click Associate. The selected QOS Spec now appears in the Associated QOS Spec column of the edited volume type.

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. In the Actions column of the volume to be encrypted, select Create Encryption to launch the Create Volume Type Encryption wizard.

3. From there, configure the Provider, Control Location, Cipher, and Key Size settings of the volume type’s encryption. The Description column describes each setting.

   Important

   The values listed below are the only supported options for Provider, Cipher, and Key Size.

   1. Enter luks for Provider.
   2. Enter aes-xts-plain64 for Cipher.
   3. Enter 256 for Key Size.
4. Click Create Volume Type Encryption.

1. Select Update Encryption from the Actions column of the volume type to launch the Update Volume Type Encryption wizard.
2. In Project > Compute > Volumes, check the Encrypted column in the Volumes table to determine whether the volume is encrypted.
3. If the volume is encrypted, click Yes in that column to view the encryption settings.

Procedure

1. Create a volume type:

   $ cinder type-create encrypt-type

2. Configure the cipher, key size, control location, and provider settings:

   $ cinder encryption-type-create --cipher aes-xts-plain64 --key-size 256 --control-location front-end encrypt-type luks

3. Create an encrypted volume:

   $ cinder --debug create 1 --volume-type encrypt-type --name DemoEncVol

Procedure

1. Edit an environment file and add a new entry to the parameter_defaults section. This ensures that the entries are updated in the containers and are retained whenever the environment is re-deployed by director with the openstack overcloud deploy command.

2. Add a new section to an environment file using CinderApiPolicies to set the consistency group settings. The equivalent parameter_defaults section with the default settings from the JSON file appear in the following way:

   parameter_defaults:
     CinderApiPolicies: { \
        cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'group:nobody' }, \
        cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'group:nobody' },  \
        cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'group:nobody' }, \
        cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'group:nobody' }, \
        cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'group:nobody' }, \
        cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'group:nobody' }, \
    }

3. The value ‘group:nobody’ determines that no group can use this feature so it is effectively disabled. To enable it, change the group to another value.

4. For increased security, set the permissions for both consistency group API and volume type management API to be identical. The volume type management API is set to "rule:admin_or_owner" by default in the same /etc/cinder/policy.json_ file:

   "volume_extension:types_manage": "rule:admin_or_owner",

5. To make the consistency groups feature available to all users, set the API policy entries to allow users to create, use, and manage their own consistency groups. To do so, use rule:admin_or_owner:

   CinderApiPolicies: { \
        cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'rule:admin_or_owner' },  \
        cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'rule:admin_or_owner’ }, \
    }

6. When you have created the environment file in /home/stack/templates/, log in as the stack user and deploy the configuration:

   $ openstack overcloud deploy --templates \
   -e /home/stack/templates/<ENV_FILE>.yaml

   Replace <ENV_FILE.yaml> with the name of the file with the ExtraConfig settings you added.

   Important

   If you passed any extra environment files when you created the overcloud, pass them again here by using the -e option to avoid making undesired changes to the overcloud.

Procedure

1. As an admin user in the dashboard, select Project > Compute > Volumes > Volume Consistency Groups.
2. Click Create Consistency Group.
3. In the Consistency Group Information tab of the wizard, enter a name and description for your consistency group. Then, specify its Availability Zone.
4. You can also add volume types to your consistency group. When you create volumes within the consistency group, the Block Storage service will apply compatible settings from those volume types. To add a volume type, click its + button from the All available volume types list.
5. Click Create Consistency Group. It appears next in the Volume Consistency Groups table.

Procedure

1. Optional: You can change the name or description of a consistency group by selecting Edit Consistency Group from its Action column.
2. To add or remove volumes from a consistency group directly, as an admin user in the dashboard, select Project > Compute > Volumes > Volume Consistency Groups.

3. Find the consistency group you want to configure. In the Actions column of that consistency group, select Manage Volumes. This launches the Add/Remove Consistency Group Volumes wizard.

   1. To add a volume to the consistency group, click its + button from the All available volumes list.
   2. To remove a volume from the consistency group, click its - button from the Selected volumes list.
4. Click Edit Consistency Group.

Procedure

1. Log in as admin user from the command line on the node that hosts the openstack-cinder-api and enter:

   # export OS_VOLUME_API_VERSION=2

   This configures the client to use version 2 of the openstack-cinder-api.

2. List all available consistency groups and their respective IDs:

   # cinder consisgroup-list

3. Create snapshots using the consistency group:

   # cinder cgsnapshot-create --name <CGSNAPNAME> --description "<DESCRIPTION>" <CGNAMEID>

   Replace:

   • <CGSNAPNAME> with the name of the snapshot (optional).
   • <DESCRIPTION> with a description of the snapshot (optional).
   • <CGNAMEID> with the name or ID of the consistency group.

4. Display a list of all available consistency group snapshots:

   # cinder cgsnapshot-list

Procedure

1. To clone an existing consistency group:

   # cinder consisgroup-create-from-src --source-cg <CGNAMEID> --name <CGNAME> --description "<DESCRIPTION>"

   Replace:

   • <CGNAMEID> is the name or ID of the consistency group you want to clone.
   • <CGNAME> is the name of your consistency group (optional).
   • <DESCRIPTION> is a description of your consistency group (optional).

2. To create a consistency group from a consistency group snapshot:

   # cinder consisgroup-create-from-src --cgsnapshot <CGSNAPNAME> --name <CGNAME> --description "<DESCRIPTION>

   Replace <CGSNAPNAME> with the name or ID of the snapshot you are using to create the consistency group.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc credentials file:

   $ source ~/stackrc

3. Use an overrides environment file or create a new one, for example multipath_overrides.yaml. Add and set the following parameter:

   parameter_defaults:
     ExtraConfig:
       cinder::config::cinder_config:
         backend_defaults/use_multipath_for_image_xfer:
           value: true

   Note

   The default settings will generate a basic multipath configuration that works for most environments. However, check with your storage vendor for recommendations, because some vendors have optimized configurations that are specific to their hardware. For more information about multipath, see the Configuring device mapper multipath guide.

4. Optional: If you have a multipath configuration file for your overcloud deployment, use the MultipathdCustomConfigFile parameter to specify the location of this file:

   1. You must copy your multipath configuration file to the /var/lib/mistral directory:

           $ sudo cp <config_file_name> /var/lib/mistral

      Replace <config_file_name> with the name of your file.

   2. Set the MultipathdCustomConfigFile parameter to this location of your multipath configuration file:

           parameter_defaults:
                MultipathdCustomConfigFile: /var/lib/mistral/<config_file_name>

      Note

      Other TripleO multipath parameters override any corresponding value in the local custom configuration file. For example, if MultipathdEnableUserFriendlyNames is False, the files on the overcloud nodes are updated to match, even if the setting is enabled in the local custom file.

      For more information about multipath parameters, see Multipath heat template parameters.

5. Include the environment file in the openstack overcloud deploy command with any other environment files that are relevant to your environment:

   $ openstack overcloud deploy \
   --templates \
   …
   -e <existing_overcloud_environment_files> \
   -e /usr/share/openstack-tripleo-heat-templates/environments/multipathd.yaml
   -e multipath_overrides.yaml \
   …

Procedure

1. Create a VM.
2. Attach a non-encrypted volume to the VM.

3. Get the name of the Compute node that contains the instance:

   $ nova show INSTANCE | grep OS-EXT-SRV-ATTR:host

   Replace INSTANCE with the name of the VM that you booted.

4. Retrieve the virsh name of the instance:

   $ nova show INSTANCE | grep instance_name

   Replace INSTANCE with the name of the VM that you booted.

5. Get the IP address of the Compute node:

   $ . stackrc
   $ nova list | grep compute_name

   Replace compute_name with the name from the output of the nova show INSTANCE command.

6. SSH into the Compute node that runs the VM:

   $ ssh heat-admin@COMPUTE_NODE_IP

   Replace COMPUTE_NODE_IP with the IP address of the Compute node.

7. Log in to the container that runs virsh:

   $ podman exec -it nova_libvirt /bin/bash

8. Enter the following command on a Compute node instance to verify that it is using multipath in the cinder volume host location:

   virsh domblklist VIRSH_INSTANCE_NAME | grep /dev/dm

   Replace VIRSH_INSTANCE_NAME with the output of the nova show INSTANCE | grep instance_name command.

   If the instance shows a value other than /dev/dm-, the connection is non-multipath and you must refresh the connection info with the nova shelve and nova unshelve commands:

   $ nova shelve <instance>
   $ nova unshelve <instance>

   Note

   If you have more than one type of back end, you must verify the instances and volumes on all back ends, because connection info that each back end returns might vary.