1. Use OpenSSL to generate an initial service token and save it in the SERVICE_TOKEN environment variable.

   # export SERVICE_TOKEN=$(openssl rand -hex 10)

2. Store the value of the administration token in a file for future use.

   # echo $SERVICE_TOKEN > ~/ks_admin_token

3. Use the openstack-config tool to set the value of the admin_token configuration key to that of the newly created token.

   # openstack-config --set /etc/keystone/keystone.conf \
   DEFAULT admin_token $SERVICE_TOKEN

• Use the openstack-config command to set the value of the connection configuration key.

  # openstack-config --set /etc/keystone/keystone.conf \
     sql connection mysql://USER:PASS@IP/DB

  Replace:

  • USER with the database user name the identity service is to use, usually keystone.
  • PASS with the password of the chosen database user.
  • IP with the IP address or host name of the database server.
  • DB with the name of the database that has been created for use by the identity service, usually keystone.

1. Open the /etc/sysconfig/iptables file in a text editor.
2. Add an INPUT rule allowing TCP traffic on ports 5000 and 35357 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

   -A INPUT -p tcp -m multiport --dports 5000,35357 -j ACCEPT

3. Save the changes to the /etc/sysconfig/iptables file.
4. Restart the iptables service to ensure that the change takes effect.

   # service iptables restart

• Use the su command to switch to the keystone user and run the keystone-manage db_sync command to initialize and populate the database identified in /etc/keystone/keystone.conf.

  # su keystone -s /bin/sh -c "keystone-manage db_sync"

Procedure 6.2. Configuring the Identity Service to work with the Object Storage Service

1. Set up the shell to access Keystone as the admin user:

   $ source ~/keystonerc_admin

2. Create the swift user and set its password by replacing PASSWORD with your chosen password:

   $ keystone user-create --name swift --pass PASSWORD

   Note the create user's ID as it will be used in subsequent steps.
3. Get the ID of the admin role:

   $ keystone role-list | grep admin

   If no admin role exists, create one:

   $ keystone role-create --name admin

4. Get the ID of the services tenant:

   $ keystone tenant-list | grep services

   If no services tenant exists, create one:

   $ keystone tenant-create --name services --description "Services Tenant" 

   This guide uses one tenant for all service users. For more information, refer to Creating the Services Tenant.
5. Add the swift user to the services tenant with the admin role:

   $ keystone user-role-add --role-id ROLEID --tenant-id TENANTID --user-id USERID

   Replace the user, role, and tenant IDs with those obtained in the previous steps.
6. Create the swift Object Storage service entry:

   $ keystone service-create --name swift --type object-store \
       --description "Swift Storage Service"

   Note the create service's ID as it will be used in the next step.
7. Create the swift endpoint entry:

   $ keystone endpoint-create --service_id SERVICEID \
       --publicurl "http://IP:8080/v1/AUTH_\$(tenant_id)s" \
       --adminurl "http://IP:8080/v1" \
       --internalurl "http://IP:8080/v1/AUTH_\$(tenant_id)s"

   Replace SERVICEID with the identifier returned by the keystone service-create command. Replace IP with the IP address of fully qualified domain name of the system hosting the Object Storage Proxy service.

Procedure 6.3. Configuring the Object Storage Service Storage Nodes

1. Format your devices using the ext4 or XFS filesystem. Make sure that xattrs are enabled.
2. Add your devices to the /etc/fstab file to ensure that they are mounted under /srv/node/ at boot time.
   Use the blkid command to find your device's unique ID, and mount the device using its unique ID.

   Note

   If using ext4, ensure that extended attributes are enabled by mounting the filesystem with the user_xattr option. (In XFS, extended attributes are enabled by default.)
3. Open the TCP ports used by each service running on each node.
   By default, the account service uses port 6002, the container service uses port 6001, and the object service uses port 6000.

   # iptables -A INPUT -p tcp -m multiport --dports 6000,6001,6002,873 -j ACCEPT
   # service iptables save
   # service iptables restart

   The -A parameter appends the rule to the end of the iptables firewall. Make sure that the rule doesn't fall after a reject-with icmp-host-prohibited rule.
4. Change the owner of the contents of /srv/node/ to swift:swift with the chown command.

   # chown -R swift:swift /srv/node/

5. Set the SELinux context correctly for all directories under /srv/node/ with the restorcon command.

   # restorecon -R /srv

6. Use the openstack-config command to add a hash prefix and suffix to your /etc/swift.conf.

   # openstack-config --set /etc/swift/swift.conf swift-hash swift_hash_path_suffix \ 
                 $(openssl rand -hex 10)
                 
   # openstack-config --set /etc/swift/swift.conf swift-hash swift_hash_path_prefix \ 
                 $(openssl rand -hex 10)

   These details are required for finding and placing data on all of your nodes. Back /etc/swift.conf up.
7. Use the openstack-config command to set the IP address your storage services will listen on. Run these commands for every service on every node in your Object Storage cluster.

   # openstack-config --set /etc/swift/object-server.conf DEFAULT bind_ip node_ip_address
   # openstack-config --set /etc/swift/account-server.conf DEFAULT bind_ip node_ip_address
   # openstack-config --set /etc/swift/container-server.conf DEFAULT bind_ip node_ip_address

   The DEFAULT argument specifies the DEFAULT section of the service configuration file. Replace node_ip_address with the IP address of the node you are configuring.
8. Copy /etc/swift.conf from the node you are currently configuring, to all of your Object Storage Service nodes.

   Important

   The /etc/swift.conf file must be identical on all of your Object Storage Service nodes.
9. Start the services which will run on your node.

   # service openstack-swift-account start
   # service openstack-swift-container start
   # service openstack-swift-object start

10. Use the chkconfig command to make sure the services automatically start at boot time.

                  
    # chkconfig openstack-swift-account on
    # chkconfig openstack-swift-container on
    # chkconfig openstack-swift-object on

Procedure 6.4. Configuring the Object Storage Service Proxy Service

1. Update the configuration file for the proxy server with the correct authentication details for the appropriate service user:

   # openstack-config --set /etc/swift/proxy-server.conf \
         filter:authtoken auth_host IP
   # openstack-config --set /etc/swift/proxy-server.conf \
         filter:authtoken admin_tenant_name services
   # openstack-config --set /etc/swift/proxy-server.conf \
         filter:authtoken admin_user swift
   # openstack-config --set /etc/swift/proxy-server.conf \
         filter:authtoken admin_password PASSWORD

   Where:

   • IP - The IP address or host name of the Identity server.
   • services - The name of the tenant that was created for the use of the Object Storage service (previous examples set this to services).
   • swift - The name of the service user that was created for the Object Storage service (previous examples set this to swift).
   • PASSWORD - The password associated with the service user.
2. Start the memcached and openstack-swift-proxy services using the service command:

   # service memcached start
   # service openstack-swift-proxy start

3. Use the chown command to change the ownership of the keystone signing directory:

   # chown swift:swift /tmp/keystone-signing-swift

4. Enable the memcached and openstack-swift-proxy services permanently using the chkconfig command:

   # chkconfig memcached on
   # chkconfig openstack-swift-proxy on

5. Allow incoming connections to the Swift proxy server by adding this firewall rule to the /etc/sysconfig/iptables configuration file:

   -A INPUT -p tcp -m multiport --dports 8080 -j ACCEPT

   Important

   This rule allows communication from all remote hosts to the system hosting the Swift proxy on port 8080. For information regarding the creation of more restrictive firewall rules refer to the Red Hat Enterprise Linux 6 Security Guide.
6. Use the service command to restart the iptables service for the new rule to take effect:

   # service iptables save
   # service iptables restart

Procedure 6.5. Building Object Storage Service Ring Files

1. Use the swift-ring-builder command to build one ring for each service. Provide a builder file, a partition power, a replica count, and the minimum hours between partition re-assignment:

   # swift-ring-builder /etc/swift/object.builder create part_power replica_count min_part_hours
   # swift-ring-builder /etc/swift/container.builder create part_power replica_count min_part_hours
   # swift-ring-builder /etc/swift/account.builder create part_power replica_count min_part_hours

2. When the rings are created, add storage devices to each ring:
   1. Add devices to the accounts ring. Repeat for each device on each node in the cluster that you want added to the ring.

      # swift-ring-builder /etc/swift/account.builder add zX-127.0.0.1:6002/device_mountpoint partition_count

      • Specify a zone with zX, where X is an integer (for example, z1 for zone one).
      • By default, all three services (account, container, and object) listen on the 127.0.0.1 address, and the above command matches this default.
        However, the service's machine IP address can also be used (for example, to handle distributed services). If you do use a real IP, remember to change the service's bind address to the same IP address or to '0.0.0.0' (configured in the /etc/swift/service-server.conf file).
      • TCP port 6002 is the default port that the account server uses.
      • The device_mountpoint is the directory under /srv/node/ that your device is mounted at.
      • The recommended minimum number for partition_count is 100, use the partition count you used to calculate your partition power.
   2. Add devices to the containers ring. Repeat for each device on each node in the cluster that you want added to the ring.

      # swift-ring-builder /etc/swift/container.builder add zX-127.0.0.1:6001/device_mountpoint partition_count

      • TCP port 6001 is the default port that the container server uses.
   3. Add devices to the objects ring. Repeat for each device on each node in the cluster that you want added to the ring.

      # swift-ring-builder /etc/swift/object.builder add zX-127.0.0.1:6000/device_mountpoint partition_count

      • TCP port 6000 is the default port that the object server uses.
3. Distribute the partitions across the devices in the ring using the swift-ring-builder command's rebalance argument.

   # swift-ring-builder /etc/swift/account.builder rebalance
   # swift-ring-builder /etc/swift/container.builder rebalance
   # swift-ring-builder /etc/swift/object.builder rebalance

4. Check to see that you now have 3 ring files in the directory /etc/swift. The command:

   # ls /etc/swift/*gz 

   should reveal:

   /etc/swift/account.ring.gz  /etc/swift/container.ring.gz  /etc/swift/object.ring.gz
   

5. Ensure that all files in the /etc/swift/ directory including those that you have just created are owned by the root user and swift group.

   Important

   All mount points must be owned by root; all roots of mounted file systems must be owned by swift. Before running the following command, ensure that all devices are already mounted and owned by root.

   # chown -R root:swift /etc/swift

6. Copy each ring builder file to each node in the cluster, storing them under /etc/swift/.

   # scp /etc/swift/*.gz node_ip_address:/etc/swift

1. Authenticate as the administrator of the identity service by running the source command on the keystonerc_admin file containing the required credentials:

   # source ~/keystonerc_admin

2. Create a user named glance for the Image service to use:

   # keystone user-create --name glance --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | 8091eaf121b641bf84ce73c49269d2d1 |
   |   name   |              glance              |
   | tenantId |                                  |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the image storage service when authenticating with the identity service. Take note of the returned user ID (used in subsequent steps).
3. Get the ID of the admin role:

   # keystone role-get admin

   If no admin role exists, create one:

   $ keystone role-create --name admin

4. Get the ID of the services tenant:

   $ keystone tenant-list | grep services

   If no services tenant exists, create one:

   $ keystone tenant-create --name services --description "Services Tenant" 

   This guide uses one tenant for all service users. For more information, refer to Creating the Services Tenant.
5. Use the keystone user-role-add command to link the glance user and the admin role together within the context of the services tenant:

   # keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID

6. Create the glance service entry:

   # keystone service-create --name glance \
           --type image \
           --description "Glance Image Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |       Glance Image Service       |
   |      id     | 7461b83f96bd497d852fb1b85d7037be |
   |     name    |              glance              |
   |     type    |               image              |
   +-------------+----------------------------------+

   Take note of the service's returned ID (used in the next step).
7. Create the glance endpoint entry:

   # keystone endpoint-create --service-id SERVICEID \
           --publicurl "http://IP:9292" \ 
           --adminurl "http://IP:9292" \  
           --internalurl "http://IP:9292"

   Replace SERVICEID with the identifier returned by the keystone service-create command. Replace IP with the IP address or host name of the system hosting the Image service.

1. Use the openstack-config command to set the value of the sql_connection configuration key in the /etc/glance/glance.conf file.

   # openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT sql_connection mysql://USER:PASS@IP/DB

   Replace:

   • USER with the database user name the Image service is to use, usually glance.
   • PASS with the password of the chosen database user.
   • IP with the IP address or host name of the database server.
   • DB with the name of the database that has been created for use by the identity service, usually glance.
2. Use the openstack-config command to set the value of the sql_connection configuration key in the /etc/glance/glance-registry.conf file.

   # openstack-config --set /etc/glance/glance-registry.conf \
      DEFAULT sql_connection mysql://USER:PASS@IP/DB

   Replace the placeholder values USER, PASS, IP, and DB with the same values used in the previous step.

1. Configure the glance-api service:

   # openstack-config --set /etc/glance/glance-api.conf \
      paste_deploy flavor keystone
   # openstack-config --set /etc/glance/glance-api.conf \
      keystone_authtoken auth_host IP
   # openstack-config --set /etc/glance/glance-api.conf \
      keystone_authtoken auth_port 35357
   # openstack-config --set /etc/glance/glance-api.conf \
      keystone_authtoken auth_protocol http
   # openstack-config --set /etc/glance/glance-api.conf \      
      keystone_authtoken admin_tenant_name services
   # openstack-config --set /etc/glance/glance-api.conf \
      keystone_authtoken admin_user glance
   # openstack-config --set /etc/glance/glance-api.conf \
      keystone_authtoken admin_password PASSWORD

2. Configure the glance-registry service:

       # openstack-config --set /etc/glance/glance-registry.conf \
      paste_deploy flavor keystone
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken auth_host IP
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken auth_port 35357   
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken auth_protocol http
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken admin_tenant_name services
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken admin_user glance
   # openstack-config --set /etc/glance/glance-registry.conf \
      keystone_authtoken admin_password PASSWORD

1. Open the /etc/glance/glance-api.conf file in a text editor, and remove any comment characters from in front of the following parameters:

   bind_host = 0.0.0.0
   bind_port = 9292

2. Open the /etc/sysconfig/iptables file in a text editor.
3. Add an INPUT rule allowing TCP traffic on port 9292 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

   -A INPUT -p tcp -m multiport --dports 9292 -j ACCEPT

4. Save the changes to the /etc/sysconfig/iptables file.
5. Restart the iptables service to ensure that the change takes effect.

   # service iptables restart

1. Use the su command to switch to the glance user.

   # su glance -s /bin/sh

2. Run the glance-manage db_sync command to initialize and populate the database identified in /etc/glance/glance-api.conf and /etc/glance/glance-registry.conf.

   # glance-manage db_sync

Procedure 7.1. Building Images using Oz

1. Use the yum command to install the oz and libguestfs-tools packages.

   # yum install -y oz libguestfs-tools

2. Download the Red Hat Enterprise Linux 6 Server installation DVD ISO file.
   Although Oz supports the use of network-based installation media, in this procedure a Red Hat Enterprise Linux 6 DVD ISO will be used.
3. Use a text editor to create a TDL file for use with Oz. The following example displays the syntax for a basic TDL file.

   Example 7.1. TDL File

   The template below can be used to create a Red Hat Enterprise Linux 6 disk image. In particular, note the use of the rootpw element to set the password for the root user and the iso element to set the path to the DVD ISO.

   <template>
    <name>rhel65_x86_64</name>
    <description>Red Hat 6.5 x86_64 template</description>
    <os>
     <name>RHEL-6</name>
     <version>4</version>
     <arch>x86_64</arch>
     <rootpw>PASSWORD</rootpw>
     <install type='iso'>
       <iso>file:///home/user/rhel-server-6.5-x86_64-dvd.iso</iso>
     </install>
    </os>
    <commands>
      <command name='console'>
   sed -i 's/ rhgb//g' /boot/grub/grub.conf
   sed -i 's/ quiet//g' /boot/grub/grub.conf
   sed -i 's/ console=tty0 / serial=tty0 console=ttyS0,115200n8 /g' /boot/grub/grub.conf
      </command>
    </commands>
   </template>

   
   
4. Run the oz-install command to build an image:

   # oz-install -u -d3 TDL_FILE

   Syntax:

   • -u ensures any required customization changes to the image are applied after guest operating installation.
   • -d3 enables the display of errors, warnings, and informational messages.
   • TDL_FILE provides the path to your TDL file.
   By default, Oz stores the resultant image in the /var/lib/libvirt/images/ directory. This location is configurable by editing the /etc/oz/oz.cfg configuration file.
5. Run the virt-sysprep command on the image to re-initialize it in preparation for upload to the Image service. Replace FILE with the path to the disk image.

   # virt-sysprep --add FILE

   Refer to the virt-sysprep manual page by running the man virt-sysprep command for information on enabling and disabling specific operations.

1. Connect to the database service using the mysql command.

   # mysql -u root -p

2. Create the cinder database.

   mysql> CREATE DATABASE cinder;

3. Create a cinder database user and grant it access to the cinder database.

   mysql> GRANT ALL ON cinder.* TO 'cinder'@'%' IDENTIFIED BY 'PASSWORD';

   mysql> GRANT ALL ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'PASSWORD';

   Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.
4. Flush the database privileges to ensure that they take effect immediately.

   mysql> FLUSH PRIVILEGES;

5. Exit the mysql client command.

   mysql> quit

1. Authenticate as the administrator of the identity service by running the source command on the keystonerc_admin file containing the required credentials.

   # source ~/keystonerc_admin

2. Create a user named cinder for the block storage service to use.

   # keystone user-create --name cinder --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | e1765f70da1b4432b54ced060139b46a |
   |   name   |              cinder              |
   | tenantId |                                  |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the block storage service when authenticating with the identity service. Take note of the created user's returned ID as it will be used in subsequent steps.
3. Get the ID of the admin role:

   # keystone role-get admin

   If no admin role exists, create one:

   $ keystone role-create --name admin

4. Get the ID of the services tenant:

   $ keystone tenant-list | grep services

   If no services tenant exists, create one:

   $ keystone tenant-create --name services --description "Services Tenant" 

   This guide uses one tenant for all service users. For more information, refer to Creating the Services Tenant.
5. Use the keystone user-role-add command to link the cinder user, admin role, and services tenant together:

   # keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID

   Replace the user, role, and tenant IDs with those obtained in the previous steps.
6. Create the cinder service entry:

   # keystone service-create --name cinder \
           --type volume \
           --description "Cinder Volume Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |      Cinder Volume Service       |
   |      id     | dfde7878671e484c9e581a3eb9b63e66 |
   |     name    |              cinder              |
   |     type    |              volume              |
   +-------------+----------------------------------+

   Take note of the created service's returned ID as it will be used in the next step.
7. Create the cinder endpoint entry.

   # keystone endpoint-create --service-id SERVICEID \
           --publicurl "http://IP:8776/v1/\$(tenant_id)s" \
           --adminurl "http://IP:8776/v1/\$(tenant_id)s" \
           --internalurl "http://IP:8776/v1/\$(tenant_id)s"

   Replace SERVICEID with the identifier returned by the keystone service-create command. Replace IP with the IP address or host name of the system that will be hosting the block storage service API (openstack-cinder-api).

   Important

   If you intend to install and run multiple instances of the API service then you must repeat this step for the IP address or host name of each instance.

1. Set the authentication strategy (auth_strategy) configuration key to keystone using the openstack-config command.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT auth_strategy keystone

2. Set the authentication host (auth_host) configuration key to the IP address or host name of the identity server.

   # openstack-config --set /etc/cinder/cinder.conf \
      keystone_authtoken auth_host IP

   Replace IP with the IP address or host name of the identity server.
3. Set the administration tenant name (admin_tenant_name) configuration key to the name of the tenant that was created for the use of the block storage service. In this guide, examples use services.

   # openstack-config --set /etc/cinder/cinder.conf \
      keystone_authtoken admin_tenant_name services

4. Set the administration user name (admin_user) configuration key to the name of the user that was created for the use of the block storage service. In this guide, examples use cinder.

   # openstack-config --set /etc/cinder/cinder.conf \
      keystone_authtoken admin_user cinder

5. Set the administration password (admin_password) configuration key to the password that is associated with the user specified in the previous step.

   # openstack-config --set /etc/cinder/cinder.conf \
      keystone_authtoken admin_password PASSWORD

1. General Settings

   Use the openstack-config utility to set the value of the rpc_backend configuration key to Qpid.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT rpc_backend cinder.openstack.common.rpc.impl_qpid

2. Use the openstack-config utility to set the value of the qpid_hostname configuration key to the host name of the Qpid server.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT qpid_hostname IP

   Replace IP with the IP address or host name of the message broker.

3. Authentication Settings

   If you have configured Qpid to authenticate incoming connections then you must provide the details of a valid Qpid user in the block storage configuration.
   1. Use the openstack-config utility to set the value of the qpid_username configuration key to the username of the Qpid user that the block storage services must use when communicating with the message broker.

      # openstack-config --set /etc/cinder/cinder.conf \
         DEFAULT qpid_username USERNAME

      Replace USERNAME with the required Qpid user name.
   2. Use the openstack-config utility to set the value of the qpid_password configuration key to the password of the Qpid user that the block storage services must use when communicating with the message broker.

      # openstack-config --set /etc/cinder/cinder.conf \
         DEFAULT qpid_password PASSWORD

      Replace PASSWORD with the password of the Qpid user.

4. Encryption Settings

   If you configured Qpid to use SSL then you must inform the block storage services of this choice. Use openstack-config utility to set the value of the qpid_protocol configuration key to ssl.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT qpid_protocol ssl

   The value of the qpid_port configuration key must be set to 5671 as Qpid listens on this different port when SSL is in use.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT qpid_port 5671

   Important

   To communicate with a Qpid message broker that uses SSL the node must also have:

   • The nss package installed.
   • The certificate of the relevant certificate authority installed in the system NSS database (/etc/pki/nssdb/).

   The certtool command is able to import certificates into the NSS database. See the certtool manual page for more information (man certtool).

1. Open the /etc/sysconfig/iptables file in a text editor.
2. Add an INPUT rule allowing TCP traffic on ports 3260 and 8776 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

   -A INPUT -p tcp -m multiport --dports 3260,8776 -j ACCEPT

3. Save the changes to the /etc/sysconfig/iptables file.
4. Restart the iptables service to ensure that the change takes effect.

   # service iptables restart

1. Use the su command to switch to the cinder user.

   # su cinder -s /bin/sh

2. Run the cinder-manage db sync command to initialize and populate the database identified in /etc/cinder/cinder.conf.

   $ cinder-manage db sync

1. Use the pvcreate command to create a physical volume.

   # pvcreate DEVICE
     Physical volume "DEVICE" successfully created

   Replace DEVICE with the path to a valid, unused, device. For example:

   # pvcreate /dev/sdX

2. Use the vgcreate command to create a volume group.

   # vgcreate cinder-volumes DEVICE
     Volume group "cinder-volumes" successfully created

   Replace DEVICE with the path to the device used when creating the physical volume. Optionally replace cinder-volumes with an alternative name for the new volume group.
3. Set the volume_group configuration key to the name of the newly created volume group.

   # openstack-config --set /etc/cinder/cinder.conf \
   DEFAULT volume_group cinder-volumes

   The name provided must match the name of the volume group created in the previous step.
4. Ensure that the correct volume driver for accessing LVM storage is in use by setting the volume_driver configuration key to cinder.volume.drivers.lvm.LVMISCSIDriver.

   # openstack-config --set /etc/cinder/cinder.conf \
   DEFAULT volume_driver cinder.volume.drivers.lvm.LVMISCSIDriver

1. Create a text file in the /etc/cinder/ directory containing a list of the NFS shares that the volume service is to use for backing storage.

   nfs1.example.com:/export
   nfs2.example.com:/export

   Each line must contain an NFS share in the format HOST:/SHARE where HOST is replaced by the IP address or host name of the NFS server and SHARE is replaced with the particular NFS share to be used.
2. Use the chown command to set the file to be owned by the root user and the cinder group.

   # chown root:cinder FILE

   Replace FILE with the path to the file containing the list of NFS shares.
3. Use the chmod command to set the file permissions such that it can be read by members of the cinder group.

   # chmod 0640 FILE

   Replace FILE with the path to the file containing the list of NFS shares.
4. Set the value of the nfs_shares_config configuration key to the path of the file containing the list of NFS shares.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT nfs_shares_config FILE

   Replace FILE with the path to the file containing the list of NFS shares.
5. The nfs_sparsed_volumes configuration key determines whether volumes are created as sparse files and grown as needed or fully allocated up front. The default and recommended value is true, which ensures volumes are initially created as sparse files.
   Setting the nfs_sparsed_volumes configuration key to false will result in volumes being fully allocated at the time of creation. This leads to increased delays in volume creation.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT nfs_sparsed_volumes true

6. Optionally, provide any additional NFS mount options required in your environment in the nfs_mount_options configuration key. If your NFS shares do not require any additional mount options or you are unsure then skip this step.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT nfs_mount_options OPTIONS

   Replace OPTIONS with the mount options to be used when accessing NFS shares. See the manual page for NFS for more information on available mount options (man nfs).
7. Ensure that the correct volume driver for accessing NFS storage is in use by setting the volume_driver configuration key to cinder.volume.drivers.nfs.NfsDriver.

   # openstack-config --set /etc/cinder/cinder.conf \
   DEFAULT volume_driver cinder.volume.drivers.nfs.NfsDriver

1. Create a text file in the /etc/cinder/ directory containing a list of the Red Hat Storage shares that the volume service is to use for backing storage.

   HOST:/VOLUME

   Each line must contain a Red Hat Storage share in the format HOST:VOLUME where HOST is replaced by the IP address or host name of the Red Hat Storage server and VOLUME is replaced with the name of a particular volume that exists on that host.
   If required additional mount options must also be added in the same way that they would be provided to the mount command line tool:

   HOST:/VOLUME -o OPTIONS

   Replace OPTIONS with a comma separated list of mount options.
2. Use the chown command to set the file to be owned by the root user and the cinder group.

   # chown root:cinder FILE

   Replace FILE with the path to the file containing the list of Red Hat Storage shares.
3. Use the chmod command to set the file permissions such that it can be read by members of the cinder group.

   # chmod 0640 FILE

   Replace FILE with the path to the file containing the list of Red Hat Storage shares.
4. Set the value of the glusterfs_shares_config configuration key to the path of the file containing the list of Red Hat Storage shares.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT glusterfs_shares_config FILE

   Replace FILE with the path to the file containing the list of Red Hat Storage shares.
5. The glusterfs_sparsed_volumes configuration key determines whether volumes are created as sparse files and grown as needed or fully allocated up front. The default and recommended value is true, which ensures volumes are initially created as sparse files.
   Setting the glusterfs_sparsed_volumes configuration key to false will result in volumes being fully allocated at the time of creation. This leads to increased delays in volume creation.

   # openstack-config --set /etc/cinder/cinder.conf \
      DEFAULT glusterfs_sparsed_volumes true

6. Ensure that the correct volume driver for accessing Red Hat Storage is in use by setting the volume_driver configuration key to cinder.volume.drivers.glusterfs.

   # openstack-config --set /etc/cinder/cinder.conf \
   DEFAULT volume_driver cinder.volume.drivers.glusterfs.GlusterfsDriver

1. Open the /etc/cinder/cinder.conf configuration file in a text editor.
2. Add a configuration block for each storage driver or volume. This configuration block must have a unique name (avoid spaces or special characters) and contain values for at least these configuration keys:

   volume_group

   A volume group name. This is the name of the volume group that will be accessed by the driver.

   volume_driver

   A volume driver. This is the name of the driver that will be used when accessing the volume group.

   volume_backend_name

   A backend name. This is an administrator-defined name for the backend, which groups the drivers so that user requests for storage served from the given backend can be serviced by any driver in the group. It is not related to the name of the configuration group which must be unique.

   Any additional driver specific configuration must also be included in the configuration block.

   [NAME]
   volume_group=GROUP
   volume_driver=DRIVER
   volume_backend_name=BACKEND

   Replace NAME with a unique name for the backend and replace GROUP with the unique name of the applicable volume group. Replace DRIVER with the driver to use when accessing this storage backend, valid values include:
   • cinder.volume.drivers.lvm.LVMISCSIDriver for LVM and iSCSI storage.
   • cinder.volume.drivers.nfs.NfsDriver for NFS storage.
   • cinder.volume.drivers.glusterfs.GlusterfsDriver for Red Hat Storage.
   Finally replace BACKEND with a name for the storage backend.
3. Update the value of the enabled_backends configuration key in the DEFAULT configuration block. This configuration key must contain a comma separated list containing the names of the configuration blocks for each storage driver.

   Example 8.1. Multiple Backend Configuration

   In this example two logical volume groups, cinder-volumes-1 and cinder-volumes-2, are grouped into the storage backend named LVM. An additional volume, backed by a list of NFS shares, is grouped into a storage backend named NFS.

   [DEFAULT]
   ...
   enabled_backends=cinder-volumes-1-driver,cinder-volumes-2-driver,cinder-volumes-3-driver
   ...
   [cinder-volumes-1-driver]
   volume_group=cinder-volumes-1
   volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
   volume_backend_name=LVM
   [cinder-volumes-2-driver]
   volume_group=cinder-volumes-2
   volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
   volume_backend_name=LVM      
   [cinder-volumes-3-driver]
   nfs_shares_config=/etc/cinder/shares.txt
   volume_driver=cinder.volume.drivers.nfs.NfsDriver
   volume_backend_name=NFS
   

   
   

   Important

   The default block storage scheduler driver in Red Hat Enterprise Linux OpenStack Platform 3 is the filter scheduler. If you have changed the value of the scheduler_driver configuration key on any of your block storage nodes then you must update the value to cinder.scheduler.filter_scheduler.FilterScheduler for the multiple storage backends feature to function correctly.
4. Save the changes to the /etc/cinder/cinder.conf file.