Procedure 2.1. Disabling the Network Manager Service

1. Verify whether Network Manager is currently enabled:

   # systemctl status NetworkManager.service | grep Active:

   • The system displays an error if the Network Manager service is not currently installed. If this error is displayed, no further action is required to disable the Network Manager service.
   • The system displays Active: active (running) if Network Manager is running, or Active: inactive (dead) if it is not. If Network Manager is inactive, no further action is required.
2. If Network Manager is running, stop it and then disable it:

   # systemctl stop NetworkManager.service
   # systemctl disable NetworkManager.service

3. Open each interface configuration file on the system in a text editor. Interface configuration files are found in the /etc/sysconfig/network-scripts/ directory and have names in the format ifcfg-X, where X is replaced by the name of the interface. Valid interface names include eth0, p1p5, and em1.
   To ensure that the standard network service takes control of the interfaces and automatically activates them on boot, confirm that the following keys are set in each interface configuration file, or add them manually:

   NM_CONTROLLED=no
   ONBOOT=yes

4. Start the standard network service:

   # systemctl start network.service

5. Configure the network service to start at boot time:

   # systemctl enable network.service

Procedure 2.2. Disabling the firewalld Service

1. Install the iptables service:

   # yum install iptables-services

2. Review the iptables rules defined in /etc/sysconfig/iptables:

   Note

   You can review your current firewalld configuration:

   # firewall-cmd --list-all

3. When you are satisfied with the iptables rules, disable firewalld:

   # systemctl disable firewalld.service

4. Stop the firewalld service and start the iptables services:

   # systemctl stop firewalld.service; systemctl start iptables.service; systemctl start ip6tables.service

5. Configure the iptables services to start at boot time:

   # systemctl enable iptables.service
   # systemctl enable ip6tables.service

Procedure 2.3. Configuring the Firewall to Allow Database Traffic

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:

   # systemctl restart iptables.service

Procedure 2.4. Starting the Database Service

1. Start the mariadb service:

   # systemctl start mariadb.service

2. Configure the mariadb service to start at boot time:

   # systemctl enable mariadb.service

Procedure 2.5. Configuring the Database Administrator Account

1. Log in to the machine on which the MariaDB service is installed.
2. Use the mysql_secure_installation to set the root password, allow remote root login, and remove the anonymous user account and test database:

   # mysql_secure_installation

Procedure 2.8. Configuring the Firewall for Message Broker Traffic

1. Open the /etc/sysconfig/iptables file in a text editor.
2. Add an INPUT rule allowing incoming connections on port 5672. 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:

   # systemctl restart iptables.service

Procedure 2.9. Launching and Configuring the RabbitMQ Message Broker for Use with OpenStack

1. Launch the rabbitmq-server service and configure it to start at boot time:

   # systemctl start rabbitmq-server.service
   # systemctl enable rabbitmq-server.service

2. When the rabbitmq-server package is installed, a guest user with a default guest password is automatically created for the RabbitMQ service. Red Hat strongly advises that you change this default password, especially if you have IPv6 available. With IPv6, RabbitMQ may be accessible from outside the network. Change the default guest password:

   # rabbitmqctl change_password guest NEW_RABBITMQ_PASS

   Replace NEW_RABBITMQ_PASS with a more secure password.
3. Create a RabbitMQ user account for the Block Storage service, the Compute service, OpenStack Networking, the Orchestration service, the Image service, and the Telemetry service:

   # rabbitmqctl add_user cinder CINDER_PASS
   # rabbitmqctl add_user nova NOVA_PASS
   # rabbitmqctl add_user neutron NEUTRON_PASS
   # rabbitmqctl add_user heat HEAT_PASS
   # rabbitmqctl add_user glance GLANCE_PASS
   # rabbitmqctl add_user ceilometer CEILOMETER_PASS

   Replace CINDER_PASS, NOVA_PASS, NEUTRON_PASS, HEAT_PASS, GLANCE_PASS, and CEILOMETER_PASS with secure passwords for each service.
4. Grant each of these RabbitMQ users read and write permissions to all resources:

   # rabbitmqctl set_permissions cinder ".*" ".*" ".*"
   # rabbitmqctl set_permissions nova ".*" ".*" ".*"
   # rabbitmqctl set_permissions neutron ".*" ".*" ".*"
   # rabbitmqctl set_permissions heat ".*" ".*" ".*"
   # rabbitmqctl set_permissions glance ".*" ".*" ".*"
   # rabbitmqctl set_permissions ceilometer ".*" ".*" ".*"

Procedure 2.10. Enabling SSL on the RabbitMQ Message Broker

1. Create a directory in which to store the required certificates:

   # mkdir /etc/pki/rabbitmq

2. Choose a secure certificate password and store it in a file within the /etc/pki/rabbitmq directory:

   # echo SSL_RABBITMQ_PW > /etc/pki/rabbitmq/certpw

   Replace SSL_RABBITMQ_PW with a certificate password. This password will be used later for further securing the necessary certificates.
3. Set the permissions for the certificate directory and password file:

   # chmod 700 /etc/pki/rabbitmq
   # chmod 600 /etc/pki/rabbitmq/certpw

4. Create the certificate database files (*.db) in the /etc/pki/rabbitmq directory, using the password in the /etc/pki/rabbitmq/certpw file:

   # certutil -N -d /etc/pki/rabbitmq -f /etc/pki/rabbitmq/certpw

5. For a production environment, it is recommended that you use a reputable third-party Certificate Authority (CA) to sign your certificates. Create a Certificate Signing Request (CSR) for a third-party CA:

   # certutil -R -d /etc/pki/rabbitmq -s "CN=RABBITMQ_HOST" \
    -a -f /etc/pki/rabbitmq/certpw > RABBITMQ_HOST.csr

   Replace RABBITMQ_HOST with the IP or host name of the server hosting the RabbitMQ message broker. This command produces a CSR named RABBITMQ_HOST.csr and a key file (keyfile.key). The key file will be used later when configuring the RabbitMQ message broker to use SSL.

   Note

   Some CAs may require additional values other than "CN=RABBITMQ_HOST".
6. Provide RABBITMQ_HOST.csr to your third-party CA for signing. Your CA should provide you with a signed certificate (server.crt) and a CA file (ca.crt). Add these files to your certificate database:

   # certutil -A -d /etc/pki/rabbitmq -n RABBITMQ_HOST -f /etc/pki/rabbitmq/certpw \
    -t u,u,u -a -i /path/to/server.crt
   # certutil -A -d /etc/pki/rabbitmq -n "Your CA certificate" \
    -f /etc/pki/rabbitmq/certpw -t CT,C,C -a -i /path/to/ca.crt

7. Configure the RabbitMQ message broker to use the certificate files for secure communications. Open the /etc/rabbitmq/rabbitmq.config configuration file in a text editor, and add the following section:

   [
     {rabbit, [
        {ssl_listeners, [5671]},
        {ssl_options, [{cacertfile,"/path/to/ca.crt"},
                       {certfile,"/path/to/server.crt"},
                       {keyfile,"/path/to/keyfile.key"},
                       {verify,verify_peer},
                       {fail_if_no_peer_cert,false}]}
      ]}
   ].

   • Replace /path/to/ca.crt with the absolute path to the CA certificate.
   • Replace /path/to/server.crt with the absolute path to the signed certificate.
   • Replace /path/to/keyfile.key with the absolute path to the key file.
8. Disable SSLv3 by editing the rabbitmq.config to include support for only specific TLS encryption versions:

   {rabbit, [
   {ssl_options, [{versions, ['tlsv1.2','tlsv1.1',tlsv1]}]},
   ]}

9. Restart the RabbitMQ service for the change to take effect:

   # systemctl restart rabbitmq-server.service

Procedure 3.2. Configuring the Identity Service SQL Database Connection

• Set the value of the connection configuration key:

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

  Replace the following values:

  • Replace USER with the Identity service database user name, usually keystone.
  • Replace PASS with the password of the database user.
  • Replace IP with the IP address or host name of the database server.
  • Replace DB with the name of the Identity service database, usually keystone.

Procedure 3.3. Setting the Identity Service Administration Token

1. Generate an initial service token and save it in the OS_SERVICE_TOKEN environment variable:

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

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

   # echo $OS_SERVICE_TOKEN > ~/ks_admin_token

3. 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 $OS_SERVICE_TOKEN

Procedure 3.5. Configuring the Firewall to Allow Identity Service Traffic

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:

   # systemctl restart iptables.service

Procedure 3.6. Populating the Identity Service Database

1. Log in to the system hosting the Identity service.
2. Switch to the keystone user and initialize and populate the database identified in /etc/keystone/keystone.conf:

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

Procedure 3.7. Limiting the Number of Entities in a Collection

1. Open the /etc/keystone/keystone.conf in a text editor.
2. Set a global value using list_limit in the [DEFAULT] section.
3. Optionally override the global value with a specific limit in individual sections. For example:

   [assignment]
   list_limit = 100
   

Procedure 4.3. Creating Identity Records for the Object Storage Service

1. Set up the shell to access keystone as the administrative user:

   # source ~/keystonerc_admin

2. Create the swift user:

   [(keystone_admin)]# keystone user-create --name swift --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | e1765f70da1b4432b54ced060139b46a |
   |   name   |              swift               |
   | username |              swift               |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the Object Storage service when authenticating with the Identity service.
3. Link the swift user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user swift --role admin --tenant services

4. Create the swift Object Storage service entry:

   [(keystone_admin)]# keystone service-create --name swift --type object-store \
       --description "Swift Storage Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |      Swift Storage Service       |
   |   enabled   |               True               |
   |      id     | 9e0156e9965241e7a7d9c839884f9c01 |
   |     name    |              swift               |
   |     type    |           object-store           |
   +-------------+----------------------------------+
   

5. Create the swift endpoint entry:

   [(keystone_admin)]# 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' \
      --region 'RegionOne'

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

Procedure 4.4. Configuring the Object Storage Service Storage Nodes

1. Format your devices using the ext4 or XFS filesystem. Ensure 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. Configure the firewall to open the TCP ports used by each service running on each node. By default, the account service uses port 6202, the container service uses port 6201, and the object service uses port 6200.
   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 6200,6201,6202,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:

      # systemctl restart iptables.service

4. Change the owner of the contents of /srv/node/ to swift:swift:

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

5. Set the SELinux context correctly for all directories under /srv/node/:

   # restorecon -R /srv

6. Add a hash prefix to the /etc/swift/swift.conf file:

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

7. Add a hash suffix to the /etc/swift/swift.conf file:

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

8. Set the IP address that the storage services will listen on. Run the following 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

   Replace NODE_IP_ADDRESS with the IP address of the node you are configuring.
9. 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.
10. Start the services that will run on the node:

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

11. Configure the services to start at boot time:

    # systemctl enable openstack-swift-account.service
    # systemctl enable openstack-swift-container.service
    # systemctl enable openstack-swift-object.service

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

   Replace the following values:

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

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

3. Configure the memcached and openstack-swift-proxy services to start at boot time:

   # systemctl enable memcached.service
   # systemctl enable openstack-swift-proxy.service

4. Allow incoming connections to the server hosting the Object Storage proxy service. Open the /etc/sysconfig/iptables file in a text editor, and Add an INPUT rule allowing TCP traffic on port 8080. The new rule must appear before any INPUT rules that REJECT traffic: :

   -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, see the Red Hat Enterprise Linux Security Guide:

   https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
5. Restart the iptables service to ensure that the change takes effect:

   # systemctl restart iptables.service

Procedure 4.6. Building Object Storage Service Ring Files

1. Build one ring for each service. Provide a builder file, a partition power, a replica count, and the minimum hours between partition reassignment:

   # 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:6202/dev_mountpt part_count

   Replace the following values:
   • Replace X with the corresponding integer of a specified zone (for example, z1 would correspond to Zone One).
   • Replace SERVICE_IP with 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.
   • Replace dev_mountpt with the /srv/node subdirectory under which your device is mounted.
   • Replace part_count with the partition count you used to calculate your partition power.

   Note

   Repeat this step for each device (on each node in the cluster) you want added to the ring.
3. Add each device to both the container and object rings:

   # swift-ring-builder /etc/swift/container.builder add zX-SERVICE_IP:6201/dev_mountpt part_count
   # swift-ring-builder /etc/swift/object.builder add zX-SERVICE_IP:6200/dev_mountpt part_count

   Replace the variables 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:

   # 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 three ring files in the directory /etc/swift:

   # ls /etc/swift/*gz 

   The files should be listed as follows:

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

6. Restart the openstack-swift-proxy service:

   # systemctl restart openstack-swift-proxy.service

7. Ensure that all files in the /etc/swift/ directory, including those that you have just created, are owned by the root user and the 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

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

Procedure 5.2. Configuring the Image Service SQL Database Connection

1. Set the value of the sql_connection configuration key in the glance-api.conf file:

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

   Replace the following values:

   • Replace USER with the Image service database user name, usually glance.
   • Replace PASS with the password of the database user.
   • Replace IP with the IP address or host name of the server hosting the database service.
   • Replace DB with the name of the Image service database, usually glance.
2. Set the value of the sql_connection configuration key in the glance-registry.conf file:

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

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

Procedure 5.3. Creating Identity Records for the Image Service

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

   # source ~/keystonerc_admin

2. Create the glance user:

   [(keystone_admin)]# keystone user-create --name glance --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |   id     | 8091eaf121b641bf84ce73c49269d2d1 |
   |  name    |              glance              |
   | username |              glance              |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the Image Service when authenticating with the Identity service.
3. Link the glance user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user glance --role admin --tenant services

4. Create the glance Image service entry:

   [(keystone_admin)]# keystone service-create --name glance \
           --type image \
           --description "Glance Image Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |       Glance Image Service       |
   |   enabled   |               True               |
   |      id     | 7461b83f96bd497d852fb1b85d7037be |
   |     name    |              glance              |
   |     type    |               image              |
   +-------------+----------------------------------+

5. Create the glance endpoint entry:

   [(keystone_admin)]#keystone endpoint-create \
           --service glance \
           --publicurl 'http://IP:9292' \ 
           --adminurl 'http://IP:9292' \  
           --internalurl 'http://IP:9292' \
           --region 'RegionOne'

   Replace IP with the IP address or host name of the server hosting the Image service.

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

Procedure 5.5. Configuring the Image Service to use the Object Storage Service

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, in the format TENANT:USER, to contain the tenant and user to use for authentication:

   # 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, replace these values 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, replace these values with the appropriate Object Storage tenant and user for your environment.
5. Set the swift_store_key configuration key to 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.6. Configuring the Firewall to Allow Image Service Traffic

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

   # systemctl restart iptables.service

Procedure 5.7. Configuring the Image Service (glance) to Use the RabbitMQ Message Broker

1. Set RabbitMQ as the notifier:

   # openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT notification_driver messaging

2. Set the name of the RabbitMQ host:

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

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

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

4. Set the RabbitMQ user name and password created for the Image service when RabbitMQ was configured:

   # openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT rabbit_userid glance
   # openstack-config --set /etc/glance/glance-api.conf \
      DEFAULT rabbit_password GLANCE_PASS

   Replace glance and GLANCE_PASS with the RabbitMQ user name and password created for the Image service.
5. When RabbitMQ was launched, the glance user was granted read and write permissions to all resources: specifically, through the virtual host /. Configure the Image service to connect to this virtual host:

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

Procedure 5.8. Populating the Image Service Database

1. Log in to the system hosting the Image service.
2. Switch to the glance user:

   # su glance -s /bin/sh

3. Initialize and populate the database identified in /etc/glance/glance-api.conf and /etc/glance/glance-registry.conf:

   $ glance-manage db_sync

Procedure 5.9. Configuring Image and Compute Services to Send and 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.13. Downloading a Test Disk Image

1. Go to https://access.redhat.com, and log in to the Red Hat Customer Portal using your customer account details.
2. Click Downloads in the menu bar.
3. Click A-Z to sort the product downloads alphabetically.
4. Click Red Hat Enterprise Linux to access the Product Downloads page.
5. Click the KVM Guest Image download link.

Procedure 5.14. Uploading a Disk Image to the Image Service

1. Set up the shell to access keystone as a configured user (an administrative account is not required):

   # source ~/keystonerc_userName

2. Import the disk image:

   [(keystone_userName)]# glance image-create --name "NAME" \
           --is-public IS_PUBLIC \
           --disk-format DISK_FORMAT \
           --container-format CONTAINER_FORMAT \
           --file IMAGE

   Replace the following values:
   • Replace NAME with a name by which users will refer to the disk image.
   • Replace IS_PUBLIC with either true or false:
     • true - All users are able to view and use the image.
     • false - Only administrators are able to view and use the image.
   • Replace DISK_FORMAT with 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.
   • Replace CONTAINER_FORMAT with 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.
   • Replace IMAGE with the local path to the image file (for uploading). 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 the --file parameter. Note that you must also specify the --copy-from argument to copy the image into the object store, otherwise the image will be accessed remotely each time it is required.
   For more information about the glance image-create syntax, see the help page:

   [(keystone_userName)]# glance help image-create

   Note the unique identifier for the image in the output of the command above.
3. Verify that your image was successfully uploaded:

    [(keystone_userName)]# glance image-show IMAGE_ID
   +------------------+--------------------------------------+
   | 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.6                             |
   | owner            | b1414433c021436f97e9e1e4c214a710     |
   | protected        | False                                |
   | size             | 25165824                             |
   | status           | active                               |
   | updated_at       | 2013-01-25T14:45:50                  |
   +------------------+--------------------------------------+

   Replace IMAGE_ID with the unique identifier for the image.

Procedure 6.2. Creating Identity Records for the Block Storage Service

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

   # source ~/keystonerc_admin

2. Create the cinder user:

   [(keystone_admin)]# keystone user-create --name cinder --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | e1765f70da1b4432b54ced060139b46a |
   |   name   |              cinder              |
   | username |              cinder              |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the Block Storage service when authenticating with the Identity service.
3. Link the cinder user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user cinder --role admin --tenant services

4. Create the cinder Block Storage service entry:

   [(keystone_admin)]# keystone service-create --name cinder \
           --type volume \
           --description "Cinder Volume Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |      Cinder Volume Service       |
   |   enabled   |               True               |
   |      id     | dfde7878671e484c9e581a3eb9b63e66 |
   |     name    |              cinder              |
   |     type    |              volume              |
   +-------------+----------------------------------+

5. Create the cinder endpoint entry:

   [(keystone_admin)]# 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' \
      --region 'RegionOne'

   Replace IP with the IP address or host name of the server hosting the Block Storage API service (openstack-cinder-api). To install and run multiple instances of the API service, 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 to keystone:

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

2. Set the Identity service host that the Block Storage services must use:

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

   Replace IP with the IP address or host name of the server hosting the Identity service.
3. Set the Block Storage services to authenticate as the correct tenant:

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

   Replace services with the name of the tenant created for the use of OpenStack Networking. Examples in this guide use services.
4. Set the Block Storage services to authenticate using the cinder administrative user account:

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

5. Set the Block Storage services to use the correct cinder administrative user account password:

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

   Replace PASSWORD with the password set when the cinder user was created.

Procedure 6.4. Configuring the Firewall to Allow Block Storage Service Traffic

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:

   # systemctl restart iptables.service

Procedure 6.5. Configuring the Block Storage Service to use the RabbitMQ Message Broker

1. Set RabbitMQ as the RPC back end:

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

2. Set the name of 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.
3. Set the message broker port to 5672:

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

4. Set the RabbitMQ username and password created for the Block Storage service when RabbitMQ was configured:

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

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

   Replace cinder and CINDER_PASS with the RabbitMQ user name and password created for the Block Storage service.
5. When RabbitMQ was launched, the cinder user was granted read and write permissions to all resources: specifically, through the virtual host /. Configure the Block Storage service to connect to this virtual host:

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

1. Enable SSL communication with the message broker:

   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT rabbit_use_ssl True
   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT kombu_ssl_certfile /path/to/client.crt
   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT kombu_ssl_keyfile /path/to/clientkeyfile.key

   Replace the following values:
   • Replace /path/to/client.crt with the absolute path to the exported client certificate.
   • Replace /path/to/clientkeyfile.key with the absolute path to the exported client key file.
2. If your certificates were signed by a third-party Certificate Authority (CA), you must also run the following command:

   # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT kombu_ssl_ca_certs /path/to/ca.crt

   Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see Section 2.3.4, “Enable SSL on the RabbitMQ Message Broker” for more information).

Procedure 6.6. Populating the Block Storage Service Database

1. Log in to the system hosting one of the Block Storage services.
2. Switch to the cinder user:

   # su cinder -s /bin/sh

3. Initialize and populate the database identified in /etc/cinder/cinder.conf:

   $ cinder-manage db sync

Procedure 6.7. Configuring openstack-cinder-volume to Use LVM Storage as a Back End

1. 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. 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 volume group created in the previous step:

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

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

Procedure 6.8. Configure a SCSI Target Daemon

1. Install the targetcli package:

   # yum install targetcli

2. Launch the target daemon and configure it to start at boot time:

   # systemctl start target.service
   # systemctl enable target.service

3. Configure the volume service to use the lioadm iSCSI target user-land tool:

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

4. Set the IP address on which the iSCSI daemon must listen (ISCSIIP):

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

   Replace ISCSI_IP with the IP address or host name of the server hosting the openstack-cinder-volume service.

Procedure 6.10. Validating the Block Storage Service Installation Locally

1. Populate the environment variables used for identifying and authenticating the administrative user:

   # source ~/keystonerc_admin

2. Verify that no errors are returned in the output of this command:

   # cinder list

3. Create a volume:

   # cinder create SIZE

   Replace SIZE with the size of the volume to create in Gigabytes (GB).
4. Remove the volume:

   # cinder delete ID

   Replace ID with the identifier returned when the volume was created.

Procedure 6.11. Validating the Block Storage Service Installation Remotely

1. Install the python-cinderclient package:

   # yum install -y python-cinderclient

2. Populate the environment variables used for identifying and authenticating the administrative user:

   # source ~/keystonerc_admin

3. Verify that no errors are returned in the output of this command:

   # cinder list

4. Create a volume:

   # cinder create SIZE

   Replace SIZE with the size of the volume to create in gigabytes (GB).
5. Remove the volume:

   # cinder delete ID

   Replace ID with the identifier returned when the volume was created.

Procedure 7.4. Creating the OpenStack Networking Database

1. Connect to the database service:

   # mysql -u root -p

2. Create the database with one of the following names:

   • If you are using the ML2 plug-in, the recommended database name is neutron_ml2
   • If you are using the Open vSwitch plug-in, the recommended database name is ovs_neutron.
   • If you are using the Linux Bridge plug-in, the recommended database name is neutron_linux_bridge.

   This example creates the ML2 neutron_ml2 database:

   mysql> CREATE DATABASE neutron_ml2 character set utf8;

3. Create a neutron database user and grant the user access to the neutron_ml2 database:

   mysql> GRANT ALL ON neutron_ml2.* TO 'neutron'@'%' IDENTIFIED BY 'PASSWORD';
   mysql> GRANT ALL ON neutron_ml2.* TO 'neutron'@'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 7.5. Configuring the OpenStack Networking SQL Database Connection

1. Set the value of the connection configuration key.

   # openstack-config --set /etc/neutron/plugin.ini \
      DATABASE sql_connection mysql://USER:PASS@IP/DB

   Replace the following values:

   • Replace USER with the OpenStack Networking database user name, usually neutron.
   • Replace PASS with the password of the database user.
   • Replace IP with the IP address or host name of the database server.
   • Replace DB with the name of the OpenStack Networking database.

   Important

   The IP address or host name specified in the connection configuration key must match the IP address or host name to which the OpenStack Networking database user was granted access when creating the OpenStack Networking database. Moreover, if the database is hosted locally and you granted permissions to 'localhost' when creating the database, you must enter 'localhost'.
2. Upgrade the OpenStack Networking database schema:

   # neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf \
      --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head

Procedure 7.6. Creating Identity Records for OpenStack Networking

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

   # source ~/keystonerc_admin

2. Create the neutron user:

   [(keystone_admin)]# keystone user-create --name neutron --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | 1df18bcd14404fa9ad954f9d5eb163bc |
   |   name   |              neutron             |
   | username |              neutron             |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by OpenStack Networking when authenticating with the Identity service.
3. Link the neutron user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user neutron --role admin --tenant services

4. Create the neutron OpenStack Networking service entry:

   [(keystone_admin)]# keystone service-create --name neutron \
      --type network \
      --description "OpenStack Networking"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |        OpenStack Networking      |
   |   enabled   |               True               |
   |      id     | 134e815915f442f89c39d2769e278f9b |
   |     name    |              neutron             |
   |     type    |              network             |
   +-------------+----------------------------------+

5. Create the neutron endpoint entry:

   [(keystone_admin)]# keystone endpoint-create
      --service neutron \
      --publicurl 'http://IP:9696' \
      --adminurl 'http://IP:9696' \
      --internalurl 'http://IP:9696' \
      --region 'RegionOne'

   Replace IP with the IP address or host name of the server that will act as the OpenStack Networking node.

Procedure 7.7. Configuring the OpenStack Networking Service to Authenticate through the Identity Service

1. Set the authentication strategy to keystone:

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

2. Set the Identity service host that OpenStack Networking must use:

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

   Replace IP with the IP address or host name of the server hosting the Identity service.
3. Set OpenStack Networking to authenticate as the correct tenant:

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

   Replace services with the name of the tenant created for the use of OpenStack Networking. Examples in this guide use services.
4. Set OpenStack Networking to authenticate using the neutron administrative user account:

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

5. Set OpenStack Networking to use the correct neutron administrative user account password:

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

   Replace PASSWORD with the password set when the neutron user was created.

Procedure 7.8. Configuring the Firewall to Allow OpenStack Networking Traffic

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

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

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

   # systemctl restart iptables.service

Procedure 7.9. Configuring the OpenStack Networking Service to use the RabbitMQ Message Broker

1. Set RabbitMQ as the RPC back end:

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

2. Set OpenStack Networking to connect to the RabbitMQ host:

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

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

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

4. Set the RabbitMQ user name and password created for OpenStack Networking when RabbitMQ was configured:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT rabbit_userid neutron
   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT rabbit_password NEUTRON_PASS

   Replace neutron and NEUTRON_PASS with the RabbitMQ user name and password created for OpenStack Networking.
5. When RabbitMQ was launched, the neutron user was granted read and write permissions to all resources: specifically, through the virtual host /. Configure the Networking service to connect to this virtual host:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT rabbit_virtual_host /

Procedure 7.10. Enabling SSL Communication Between OpenStack Networking and the RabbitMQ Message Broker

1. Enable SSL communication with the message broker:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT rabbit_use_ssl True
   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT kombu_ssl_certfile /path/to/client.crt
   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT kombu_ssl_keyfile /path/to/clientkeyfile.key

   Replace the following values:
   • Replace /path/to/client.crt with the absolute path to the exported client certificate.
   • Replace /path/to/clientkeyfile.key with the absolute path to the exported client key file.
2. If your certificates were signed by a third-party Certificate Authority (CA), you must also run the following command:

   # openstack-config --set /etc/neutron/neutron.conf \
    DEFAULT kombu_ssl_ca_certs /path/to/ca.crt

   Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see Section 2.3.4, “Enable SSL on the RabbitMQ Message Broker” for more information).

Procedure 7.11. Configuring OpenStack Networking to Communicate with the Compute Service

1. Set OpenStack Networking to connect to the Compute controller node:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_url http://CONTROLLER_IP:8774/v2

   Replace CONTROLLER_IP with the IP address or host name of the Compute controller node.
2. Set the user name, password, and tenant for the nova user:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_admin_username nova
   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_admin_tenant_id TENANT_ID
   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_admin_password PASSWORD

   Replace TENANT_ID with the unique identifier of the tenant created for the use of the Compute service. Replace PASSWORD with the password set when the nova user was created.
3. Set OpenStack Networking to connect to the Compute controller node in an administrative context:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_admin_auth_url http://CONTROLLER_IP:35357/v2.0

   Replace CONTROLLER_IP with the IP address or host name of the Compute controller node.
4. Set OpenStack Networking to use the correct region for the Compute controller node:

   # openstack-config --set /etc/neutron/neutron.conf \
      DEFAULT nova_region_name RegionOne

Procedure 7.14. Configuring the Open vSwitch Plug-in Agent

1. Start the openvswitch service:

   # systemctl start openvswitch.service

2. Configure the openvswitch service to start at boot time:

   # systemctl enable openvswitch.service

3. Each host running the Open vSwitch agent requires an Open vSwitch bridge called br-int. This bridge is used for private network traffic:

   # ovs-vsctl add-br br-int

   Warning

   The br-int bridge is required for the agent to function correctly. Once created, do not remove or otherwise modify the br-int bridge.
4. Ensure that the br-int device persists on reboot by creating a /etc/sysconfig/network-scripts/ifcfg-br-int file, and adding the following lines:

   DEVICE=br-int
   DEVICETYPE=ovs
   TYPE=OVSBridge
   ONBOOT=yes
   BOOTPROTO=none

5. Set the value of the bridge_mappings configuration key to a comma-separated list of physical networks and the network bridges associated with them:

   # openstack-config --set /etc/neutron/plugin.ini \
      OVS bridge_mappings PHYSNET:BRIDGE

   Replace PHYSNET with the name of a physical network, and replace BRIDGE with the name of the network bridge.
6. Start the neutron-openvswitch-agent service:

   # systemctl start neutron-openvswitch-agent.service

7. Configure the neutron-openvswitch-agent service to start at boot time:

   # systemctl enable neutron-openvswitch-agent.service

8. Configure the neutron-ovs-cleanup service to start at boot time. This service ensures that the OpenStack Networking agents maintain full control over the creation and management of tap devices:

   # systemctl enable neutron-ovs-cleanup.service

Procedure 7.15. Configuring the Linux Bridge Plug-in Agent

1. Set the value of the physical_interface_mappings configuration key to a comma-separated list of physical networks and the VLAN ranges associated with them that are available for allocation to tenant networks:

   # openstack-config --set /etc/neutron/plugin.ini \
      LINUX_BRIDGE physical_interface_mappings PHYSNET:VLAN_START:VLAN_END

   Replace the following values:
   • Replace PHYSNET with the name of a physical network.
   • Replace VLAN_START with an identifier indicating the start of the VLAN range.
   • Replace VLAN_END with an identifier indicating the end of the VLAN range.
2. Start the neutron-linuxbridge-agent service:

   # systemctl start neutron-linuxbridge-agent.service

3. Configure the neutron-linuxbridge-agent service to start at boot time:

   # systemctl enable neutron-linuxbridge-agent.service

Procedure 8.1. Installing the Compute VNC proxy packages

• Install the VNC proxy utilities and the console authentication service:
  • Install the openstack-nova-novncproxy package using the yum command:

    # yum install -y openstack-nova-novncproxy

  • Install the openstack-nova-console package using the yum command:

    # yum install -y openstack-nova-console

Procedure 8.2. Configuring the firewall to allow Compute VNC proxy traffic

1. Edit the /etc/sysconfig/iptables file and add the following on a new line underneath the -A INPUT -i lo -j ACCEPT line and before any -A INPUT -j REJECT rules:

   -A INPUT -m state --state NEW -m tcp -p tcp --dport 6080 -j ACCEPT

2. Save the file and exit the editor.

• Similarly, when using the openstack-nova-xvpvncproxy service, enable traffic on TCP port 6081 with the following on a new line in the same location:

  -A INPUT -m state --state NEW -m tcp -p tcp --dport 6081 -j ACCEPT

Procedure 8.3. Creating the Compute Service Database

1. Connect to the database service:

   # mysql -u root -p

2. Create the nova database:

   mysql> CREATE DATABASE nova;

3. Create a nova database user and grant the user access to the nova database:

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

   mysql> GRANT ALL ON nova.* TO 'nova'@'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 8.4. Configuring the Compute Service SQL Database Connection

• Set the value of the sql_connection configuration key:

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

  Replace the following values:

  • Replace USER with the Compute service database user name, usually nova.
  • Replace PASS with the password of the database user.
  • Replace IP with the IP address or host name of the database server.
  • Replace DB with the name of the Compute service database, usually nova.

Procedure 8.5. Creating Identity Records for the Compute Service

1. Set up the shell to access keystone as the administrative user:

   # source ~/keystonerc_admin

2. Create the compute user:

   [(keystone_admin)]# keystone user-create --name compute --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | 96cd855e5bfe471ce4066794bbafb615 |
   |   name   |              compute             |
   | username |              compute             |
   +----------+----------------------------------+
   

   Replace PASSWORD with a secure password that will be used by the Compute service when authenticating with the Identity service.
3. Link the compute user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user compute --role admin --tenant services

4. Create the compute service entry:

   [(keystone_admin)]# keystone service-create --name compute \
      --type compute \
      --description "OpenStack Compute Service"
   +-------------+----------------------------------+
   |   Property  |              Value               |
   +-------------+----------------------------------+
   | description |     OpenStack Compute Service    |
   |   enabled   |               True               |
   |      id     | 8dea97f5ee254b309c1792d2bd821e59 |
   |     name    |              compute             |
   |     type    |              compute             |
   +-------------+----------------------------------+

5. Create the compute endpoint entry:

   [(keystone_admin)]# keystone endpoint-create \
      --service compute
      --publicurl "http://IP:8774/v2/%(tenant_id)s" \
      --adminurl "http://IP:8774/v2/%(tenant_id)s" \
      --internalurl "http://IP:8774/v2/%(tenant_id)s" \
      --region 'RegionOne'

   Replace IP with the IP address or host name of the system hosting the Compute API service.

Procedure 8.6. Configuring the Compute Service to Authenticate Through the Identity Service

1. Set the authentication strategy to keystone:

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

2. Set the Identity service host that the Compute service must use:

   # openstack-config --set /etc/nova/api-paste.ini \
      filter:authtoken auth_host IP

   Replace IP with the IP address or host name of the server hosting the Identity service.
3. Set the Compute service to authenticate as the correct tenant:

   # openstack-config --set /etc/nova/api-paste.ini \
      filter:authtoken admin_tenant_name services

   Replace services with the name of the tenant created for the use of the Compute service. Examples in this guide use services.
4. Set the Compute service to authenticate using the compute administrative user account:

   # openstack-config --set /etc/nova/api-paste.ini \
      filter:authtoken admin_user compute

5. Set the Compute service to use the correct compute administrative user account password:

   # openstack-config --set /etc/nova/api-paste.ini \
      filter:authtoken admin_password PASSWORD

   Replace PASSWORD with the password set when the compute user was created.

Procedure 8.7. Configuring the Firewall to Allow Compute Service Traffic

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

   -A INPUT -p tcp -m multiport --dports 5900:5999 -j ACCEPT

3. Add an INPUT rule allowing TCP traffic on port 8774. The new rule must appear before any INPUT rules that REJECT traffic:

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

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

   # systemctl restart iptables.service

Procedure 8.8. Configuring the Compute Service to use the RabbitMQ Message Broker

1. Set RabbitMQ as the RPC back end:

   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT rpc_backend rabbit

2. Set the Compute service to connect to the RabbitMQ host:

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

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

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

4. Set the RabbitMQ user name and password created for the Compute service when RabbitMQ was configured:

   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT rabbit_userid nova
   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT rabbit_password NOVA_PASS

   Replace nova and NOVA_PASS with the RabbitMQ user name and password created for the Compute service.
5. When RabbitMQ was launched, the nova user was granted read and write permissions to all resources: specifically, through the virtual host /. Configure the Compute service to connect to this virtual host:

   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT rabbit_virtual_host /

Procedure 8.9. Enabling SSL Communication Between the Compute Service and the RabbitMQ Message Broker

1. Enable SSL communication with the message broker:

   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT rabbit_use_ssl True
   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT kombu_ssl_certfile /path/to/client.crt
   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT kombu_ssl_keyfile /path/to/clientkeyfile.key

   Replace the following values:
   • Replace /path/to/client.crt with the absolute path to the exported client certificate.
   • Replace /path/to/clientkeyfile.key with the absolute path to the exported client key file.
2. If your certificates were signed by a third-party Certificate Authority (CA), you must also run the following command:

   # openstack-config --set /etc/nova/nova.conf \
      DEFAULT kombu_ssl_ca_certs /path/to/ca.crt

   Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see Section 2.3.4, “Enable SSL on the RabbitMQ Message Broker” for more information).

Procedure 8.11. Populating the Compute Service Database

1. Log in to a system hosting an instance of the openstack-nova-conductor service.
2. Switch to the nova user:

   # su nova -s /bin/sh

3. Initialize and populate the database identified in /etc/nova/nova.conf:

   $ nova-manage db sync

Procedure 8.12. Launching Compute Services

1. Libvirt requires that the messagebus service be enabled and running. Start the service:

   # systemctl start messagebus.service

2. The Compute service requires that the libvirtd service be enabled and running. Start the service and configure it to start at boot time:

   # systemctl start libvirtd.service
   # systemctl enable libvirtd.service

3. Start the API service on each system that is hosting an instance of it. Note that each API instance should either have its own endpoint defined in the Identity service database or be pointed to by a load balancer that is acting as the endpoint. Start the service and configure it to start at boot time:

   # systemctl start openstack-nova-api.service
   # systemctl enable openstack-nova-api.service

4. Start the scheduler on each system that is hosting an instance of it. Start the service and configure it to start at boot time:

   # systemctl start openstack-nova-scheduler.service
   # systemctl enable openstack-nova-scheduler.service

5. Start the conductor on each system that is hosting an instance of it. Note that it is recommended that this service is not run on every Compute node as this eliminates the security benefits of restricting direct database access from the Compute nodes. Start the service and configure it to start at boot time:

   # systemctl start openstack-nova-conductor.service
   # systemctl enable openstack-nova-conductor.service

6. Start the Compute service on every system that is intended to host virtual machine instances. Start the service and configure it to start at boot time:

   # systemctl start openstack-nova-compute.service
   # systemctl enable openstack-nova-compute.service

7. Depending on your environment configuration, you may also need to start the following services:

   openstack-nova-cert

   The X509 certificate service, required if you intend to use the EC2 API to the Compute service.

   Note

   To use the EC2 API to the Compute service, you must set the options in the nova.conf configuration file. For more information, see Configuring the EC2 API section in the Red Hat Enterprise Linux OpenStack Platform Configuration Reference Guide. This document is available from the following link:

   https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform

   openstack-nova-network

   The Nova networking service. Note that you must not start this service if you have installed and configured, or intend to install and configure, OpenStack Networking.

   openstack-nova-objectstore

   The Nova object storage service. It is recommended that the Object Storage service (Swift) is used for new deployments.

Procedure 9.1. Configuring the Orchestration Service Database

1. Connect to the database service:

   # mysql -u root -p

2. Create the heat database:

   mysql> CREATE DATABASE heat;

3. Create a database user named heat and grant the user access to the heat database:

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

   Replace PASSWORD with a secure password that will be user 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

6. Set the value of the sql_connection configuration key:

   # openstack-config --set /etc/heat/heat.conf \
      DEFAULT sql_connection mysql://heat:PASSWORD@IP/heat

   Replace the following values:
   • Replace PASSWORD with the password of the heat database user.
   • Replace IP with the IP address or host name of the database server.
7. As the heat user, sync the database:

   # runuser -s /bin/sh heat -c "heat-manage db_sync"

Procedure 9.2. Creating Identity Records for the Orchestration Service

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

   # source ~/keystonerc_admin

2. Create the heat user:

   [(keystone_admin)]# keystone user-create --name heat --pass PASSWORD
   +----------+----------------------------------+
   | Property |              Value               |
   +----------+----------------------------------+
   |  email   |                                  |
   | enabled  |               True               |
   |    id    | 96cd855e5bfe471ce4066794bbafb615 |
   |   name   |               heat               |
   | username |               heat               |
   +----------+----------------------------------+

   Replace PASSWORD with a password that will be used by the Orchestration service when authenticating with the Identity service.
3. Link the heat user and the admin role together within the context of the services tenant:

   [(keystone_admin)]# keystone user-role-add --user heat --role admin --tenant services

4. Create the heat and heat-cfn service entries:

   [(keystone_admin)]# keystone service-create --name heat \
      --type orchestration
   # keystone service-create --name heat-cfn \
      --type cloudformation

5. Create endpoint entries for the heat service and the heat-cfn service:

   [(keystone_admin)]# keystone endpoint-create \
      --service heat-cfn \
      --publicurl 'HEAT_CFN_IP:8000/v1' \
      --adminurl 'HEAT_CFN_IP:8000/v1' \
      --internalurl 'HEAT_CFN_IP:8000/v1' \
      --region 'RegionOne'
   [(keystone_admin)]# keystone endpoint-create \
      --service heat \
      --publicurl 'HEAT_IP:8004/v1/%(tenant_id)s' \
      --adminurl 'HEAT_IP:8004/v1/%(tenant_id)s' \
      --internalurl 'HEAT_IP:8004/v1/%(tenant_id)s' \
      --region 'RegionOne'

   Replace the following values:
   • Replace HEAT_CFN_IP with the IP or host name of the system hosting the heat-cfn service.
   • Replace HEAT_IP with the IP or host name of the system hosting the heat service.

   Important

   Include the http:// prefix for HEAT_CFN_IP and HEAT_IP values.