Procedure 2.4. Configuring the firewall to allow database traffic (for Red Hat Enterprise Linux 6-based systems)

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

   -A INPUT -p tcp -m multiport --dports 3306 -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

Procedure 2.5. Configuring the firewall to allow database traffic (for Red Hat Enterprise Linux 7-based systems)

1. Add a rule allowing TCP traffic on port 3306:

   # firewall-cmd --permanent --add-port=3306/tcp

2. For the change to take immediate effect, add the rule to the runtime mode:

   # firewall-cmd --add-port=3306/tcp

Procedure 2.6. Start the database service (for Red Hat Enterprise Linux 6-based systems)

1. Use the service command to start the mysqld service:

   # service start mysqld

2. Use the chkconfig command to ensure that mysqld service will be started automatically in the future:

   # chkconfig mysqld on

Procedure 2.7. Start the database service (for Red Hat Enterprise Linux 7-based systems)

1. Use the systemctl command to start the mariadb.service:

   # systemctl start mariadb.service

2. Use the systemctl command to ensure that mariadb.service will be started automatically in the future:

   # systemctl enable mariadb.service

Procedure 2.8. Configuring the Database Administrator Account

1. Log in to the machine on which the MariaDB server is installed.
2. Set a password for the local root user:

   # mysqladmin -u root password "PASSWORD"

3. Optionally, configure a user account for remote access:
   1. Use the mysql client to connect to the MariaDB server:

      # mysql -p

   2. Enter the newly configured password for the root database user account:

      Enter password:

   3. Create a user called root that can access the MariaDB server from remote machines:

      MariaDB [(none)]> CREATE USER 'root'@'%' IDENTIFIED BY 'PASSWORD';

   4. Grant the newly created user access to resources in the database:

      MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';

4. Exit the mysql client:

   MariaDB [(none)]> \q

Procedure 2.11. Configuring the firewall for message broker traffic (for Red Hat Enterprise Linux 6-based systems)

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

   -A INPUT -p tcp -m tcp --dport 5672  -j ACCEPT

3. Save the changes to the /etc/sysconfig/iptables file.
4. Restart the iptables service for the firewall changes to take effect.

   # service iptables restart

Procedure 2.12. Configuring the firewall for message broker traffic (for Red Hat Enterprise Linux 7-based systems)

1. Add a rule allowing incoming connections on port 5672:

   # firewall-cmd --permanent --add-port=5672/tcp

2. For the change to take immediate effect, add the rule to the runtime mode:

   # firewall-cmd --add-port=5672/tcp

Procedure 3.2. Setting the Identity Service administrative token

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

Procedure 3.3. Configuring the Identity Service SQL database connection

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

Procedure 3.5. Configuring the firewall to allow Identity Service traffic (for Red Hat Enterprise Linux 6-based systems)

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

Procedure 3.6. Configuring the firewall to allow Identity Service traffic (for Red Hat Enterprise Linux 7-based systems)

1. Add rules allowing TCP traffic on port 5000 and 35357:

   # firewall-cmd --permanent --add-port=5000/tcp

   # firewall-cmd --permanent --add-port=35357/tcp

2. For the change to take immediate effect, add the rules to the runtime mode:

   # firewall-cmd --add-port=5000/tcp

   # firewall-cmd --add-port=35357/tcp

Procedure 3.7. Populating the Identity Service database

1. Log in to the system hosting the Identity service.
2. 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 4.2. Configuring the Object Storage Service to authenticate through the Identity 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

3. Add the swift user to the services tenant with the admin role:

   # keystone user-role-add --user swift --role admin --tenant services

4. Create the swift Object Storage service entry:

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

5. Create the swift endpoint entry:

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

   Replace IP with the IP address or fully qualified domain name of the system hosting the Object Storage Proxy service.

Procedure 4.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. For Red Hat Enterprise Linux 6-based systems, configure the firewall to 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.
   1. Open the /etc/sysconfig/iptables file in a text editor.
   2. Add an INPUT rule allowing TCP traffic on the ports used by the account, container, and object service. The new rule must appear before any reject-with icmp-host-prohibited rule.

      -A INPUT -p tcp -m multiport --dports 6000,6001,6002,873 -j ACCEPT

   3. Save the changes to the /etc/sysconfig/iptables file.
   4. Restart the iptables service for the firewall changes to take effect.

      # service iptables restart

4. For Red Hat Enterprise Linux 7-based systems, configure the firewall to 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.
   1. Add rules allowing TCP traffic on the ports used by the account, container, and object service.

      # firewall-cmd --permanent --add-port=6000-6002/tcp

      # firewall-cmd --permanent --add-port=873/tcp

   2. For the change to take immediate effect, add the rules to the runtime mode:

      # firewall-cmd --add-port=6000-6002/tcp

      # firewall-cmd --add-port=873/tcp

5. Change the owner of the contents of /srv/node/ to swift:swift with the chown command.

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

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

   # restorecon -R /srv

7. Use the openstack-config command to add a hash prefix (swift_hash_path_prefix) to your /etc/swift/swift.conf:

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

8. Use the openstack-config command to add a hash suffix (swift_hash_path_suffix) to your /etc/swift/swift.conf:

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

   These details are required for finding and placing data on all of your nodes. Back /etc/swift/swift.conf up.
9. 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.
10. Copy /etc/swift/swift.conf from the node you are currently configuring, to all of your Object Storage Service nodes.

    Important

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

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

12. 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 4.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. Enable the memcached and openstack-swift-proxy services permanently using the chkconfig command:

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

4. For Red Hat Enterprise Linux 6-based systems, 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 Security Guide from the following link:

   https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
5. For Red Hat Enterprise Linux 7-based systems, allow incoming connections to the Swift proxy server by adding this firewall rule:

   firewall-cmd --permanent --add-port=8080/tcp

   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 Security Guide from the following link:

   https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
6. For the change to take immediate effect, add the rule to the runtime mode:

   firewall-cmd --add-port=8080/tcp

7. Use the service command to restart the iptables service for the new rule to take effect:

   # service iptables save
   # service iptables restart

Procedure 4.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 devices to the account ring.

   # swift-ring-builder /etc/swift/account.builder add zX-SERVICE_IP:6002/dev_mountpt part_count

   Where:
   • X is the corresponding integer of a specified zone (for example, z1 would correspond to Zone One).
   • SERVICE_IP is the IP on which the account, container, and object services should listen. This IP should match the bind_ip value set during the configuration of the Object Storage service Storage Nodes.
   • dev_mountpt is the /srv/node subdirectory under which your device is mounted.
   • part_count is the partition count you used to calculate your partition power.
   For example, if:
   • The account, container, and object services are configured to listen on 10.64.115.44 on Zone One,
   • Your device is mounted on /srv/node/accounts, and
   • You wish to set a partition count of 100.
   Then run:

   # swift-ring-builder /etc/swift/account.builder add z1-10.64.115.44:6002/accounts 100

   Note

   Repeat this step for each device (on each node in the cluster) you want added to the ring.
3. In a similar fashion, add devices to both containers and objects rings:

   # swift-ring-builder /etc/swift/container.builder add zX-SERVICE_IP:6001/dev_mountpt part_count

   # swift-ring-builder /etc/swift/object.builder add zX-SERVICE_IP:6000/dev_mountpt part_count

   Replace the variables herein with the same ones used in the previous step.

   Note

   Repeat these commands for each device (on each node in the cluster) you want added to the ring.
4. 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

5. 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
   

6. 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

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

Procedure 5.2. Configuring the Image Service to authenticate through the Identity Service

1. Authenticate as the administrator of the Identity service by running the source command on the keystonerc_admin file:

   # 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 Service when authenticating with the Identity service.
3. 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 glance --role admin --tenant services

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

5. Create the glance endpoint entry:

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

   Replace IP with the IP address or host name of the system hosting the Image Service.

Procedure 5.3. Configuring the Image Service SQL database connection

1. Use the openstack-config command to set the value of the sql_connection configuration key in the /etc/glance/glance-api.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 Image 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.

Procedure 5.4. Configuring the Image Service to authenticate through the Identity Service

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. Set the default_store configuration key to swift:

   #openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT default_store swift

2. Set the swift_store_auth_address configuration key to the public endpoint for the Identity service:

   #openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT swift_store_auth_address http://IP:5000/v2.0/

3. Add the container for storing images in the Object Storage Service:

   #openstack-config --set /etc/glance/glance-api.conf \
    DEFAULT swift_store_create_container_on_put True

4. Set the swift_store_user configuration key to contain the tenant and user to use for authentication in the format TENANT:USER:

   #openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT swift_store_user services:swift

   • If you followed the instructions in this guide to deploy Object Storage, these values must be replaced with the services tenant and the swift user respectively (as shown in the command example above).
   • If you did not follow the instructions in this guide to deploy Object Storage, these values must be replaced with the appropriate Object Storage tenant and user for your environment.
5. Set the swift_store_key configuration key to the password of the user to be used for authentication (that is, the password that was set for the swift user when deploying the Object Storage service.

   #openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT swift_store_key PASSWORD

Procedure 5.5. Configuring the firewall to allow Image Service traffic (for Red Hat Enterprise Linux 6-based systems)

1. Open the /etc/glance/glance-api.conf file in a text editor, and remove any comment characters preceding 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

Procedure 5.6. Configuring the firewall to allow Image Service traffic (for Red Hat Enterprise Linux 7-based systems)

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

   bind_host = 0.0.0.0
   bind_port = 9292

2. Add a rule allowing TCP traffic on port 9292 to the file.

   # firewall-cmd --permanent --add-port=9292/tcp

3. For the change to take immediate effect, add the rule to the runtime mode:

   # firewall-cmd --add-port=9292/tcp

Procedure 5.7. Populating the Image Service database

1. Log in to the system hosting the Image service.
2. Use the su command to switch to the glance user.

   # su glance -s /bin/sh

3. 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 5.8. Configuring Image and Compute services to send/receive images through the local file system

1. Create a JSON document that exposes the Image file system metadata required by openstack-nova-compute.
2. Configure the Image service to use the JSON document.
3. Configure openstack-nova-compute to use the file system metadata provided by the Image service.

Procedure 5.12. 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 5.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 / console=ttyS0,115200n8 console=tty0 /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. Set the environment variables used for authenticating with the Identity service by loading them from the keystonerc file associated with your user (an administrative account is not required):

   # source ~/keystonerc_userName

2. Use the glance image-create command to import your disk image:

   # glance image-create --name "NAME" \
           --is-public IS_PUBLIC \
           --disk-format DISK_FORMAT \
           --container-format CONTAINER_FORMAT \
           --file IMAGE

   Where:
   • NAME = The name by which users will refer to the disk image.
   • IS_PUBLIC = Either true or false:
     • true - All users will be able to view and use the image.
     • false - Only administrators will be able to view and use the image.
   • DISK_FORMAT = The disk image's format. Valid values include: aki, ami, ari, iso, qcow2, raw, vdi, vhd, and vmdk.
     If the format of the virtual machine disk image is unknown, use the qemu-img info command to try and identify it.
     ⁠

     Example 5.2. Using qemu-img info

     In the following example, the qemu-img info is used to determine the format of a disk image stored in the file ./RHEL65.img.

     # qemu-img info ./RHEL65.img
     image: ./RHEL65.img
     file format: qcow2
     virtual size: 5.0G (5368709120 bytes)
     disk size: 136K
     cluster_size: 65536

   • CONTAINER_FORMAT = The container format of the image. The container format is bare unless the image is packaged in a file format such as ovf or ami that includes additional metadata related to the image.
   • IMAGE = The local path to the image file (for uploading).
   For more information about the glance image-create syntax, execute:

   # glance help image-create

   Note

   If the image being uploaded is not locally accessible but is available using a remote URL, provide the URL using the --location parameter instead of using the --file parameter.

   However, unless you also specify the --copy-from argument, the Image service will not copy the image into the object store. Instead, the image will be accessed remotely each time it is required.
   ⁠

   Example 5.3. Uploading an Image to the Image service

   In this example the qcow2 format image in the file named RHEL65.img is uploaded to the Image service. It is created in the service as a publicly accessible image named RHEL 6.5.

   # glance image-create --name "RHEL 6.5" --is-public true --disk-format qcow2 \
             --container-format bare \
             --file RHEL65.img
   +------------------+--------------------------------------+
   | Property         | Value                                |
   +------------------+--------------------------------------+
   | checksum         | 2f81976cae15c16ef0010c51e3a6c163     |
   | container_format | bare                                 |
   | created_at       | 2013-01-25T14:45:48                  |
   | deleted          | False                                |
   | deleted_at       | None                                 |
   | disk_format      | qcow2                                |
   | id               | 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9 |
   | is_public        | True                                 |
   | min_disk         | 0                                    |
   | min_ram          | 0                                    |
   | name             | RHEL 6.5                             |
   | owner            | b1414433c021436f97e9e1e4c214a710     |
   | protected        | False                                |
   | size             | 25165824                             |
   | status           | active                               |
   | updated_at       | 2013-01-25T14:45:50                  |
   +------------------+--------------------------------------+

3. To verify that your image was successfully uploaded, use the glance image-list command:

    # glance image-list
   +--------------+----------+-------------+------------------+----------+--------+
   | ID           | Name     | Disk Format | Container Format |Size      | Status |
   +--------------+----------+-------------+------------------+----------+--------+
   | 0ce782c6-... | RHEL 6.5 | qcow2       | bare             |213581824 | active |
   +--------------+----------+-------------+------------------+----------+--------+

   To view detailed information about an uploaded image, execute the glance image-show command using the image's identifier:

   # glance image-show 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9
   +------------------+--------------------------------------+
   | Property         | Value                                |
   +------------------+--------------------------------------+
   | checksum         | 2f81976cae15c16ef0010c51e3a6c163     |
   | container_format | bare                                 |
   | created_at       | 2013-01-25T14:45:48                  |
   | deleted          | False                                |
   | disk_format      | qcow2                                |
   | id               | 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9 |
   | is_public        | True                                 |
   | min_disk         | 0                                    |
   | min_ram          | 0                                    |
   | name             | RHEL 6.5                             |
   | owner            | b1414433c021436f97e9e1e4c214a710     |
   | protected        | False                                |
   | size             | 25165824                             |
   | status           | active                               |
   | updated_at       | 2013-01-25T14:45:50                  |
   +------------------+--------------------------------------+

Procedure 6.1. Creating the database to be used by Block Storage Services

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.

   mysql> quit

Procedure 6.2. Creating Identity records for the Block Storage service

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.
3. Use the keystone user-role-add command to link the cinder user, admin role, and services tenant together:

   # keystone user-role-add --user cinder --role admin --tenant services

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

5. Create the cinder endpoint entry.

   # keystone endpoint-create \
           --service cinder \
           --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 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.

Procedure 6.3. Configuring the Block Storage Service to authenticate through the Identity Service

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

Procedure 6.4. Configuring the Block Storage service to use the RabbitMQ message broker

1. Log in as root to the system hosting the Block Storage services.
2. In /etc/cinder/cinder.conf, set RabbitMQ as the RPC back end.

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

3. Set the Block Storage service to connect to the RabbitMQ host:

   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT rabbit_host RABBITMQ_HOST

   Replace RABBITMQ_HOST with the IP address or host name of the message broker.
4. Set the message broker port to 5672:

   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT rabbit_port 5672

5. Set the RabbitMQ username and password created for the Block Storage service:

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

   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT rabbit_password CINDER_PASS

   Where cinder and CINDER_PASS are the RabbitMQ username and password created for Block Storage (in Section 2.4.2, “Install and Configure the RabbitMQ Message Broker”).