Chapter 4. Installing the undercloud

The first step to creating your Red Hat OpenStack Platform environment is to install the director on the undercloud system. This involves a few prerequisite steps to enable the necessary subscriptions and repositories.

4.1. Creating the stack user

The director installation process requires a non-root user to execute commands. Use the following procedure to create the user named stack and set a password.


  1. Log into your undercloud as the root user.
  2. Create the stack user:

    [root@director ~]# useradd stack
  3. Set a password for the user:

    [root@director ~]# passwd stack
  4. Disable password requirements when using sudo:

    [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@director ~]# chmod 0440 /etc/sudoers.d/stack
  5. Switch to the new stack user:

    [root@director ~]# su - stack
    [stack@director ~]$

Continue the director installation as the stack user.

4.2. Creating directories for templates and images

The director uses system images and Heat templates to create the overcloud environment. To keep these files organized, we recommend creating directories for images and templates:

[stack@director ~]$ mkdir ~/images
[stack@director ~]$ mkdir ~/templates

4.3. Setting the undercloud hostname

The undercloud requires a fully qualified domain name for its installation and configuration process. The DNS server that you use must be able to resolve a fully qualified domain name. For example, you can use an internal or private DNS server. This means that you might need to set the hostname of your undercloud.


  1. Check the base and full hostname of the undercloud:

    [stack@director ~]$ hostname
    [stack@director ~]$ hostname -f
  2. If either of the previous commands do not report the correct fully-qualified hostname or report an error, use hostnamectl to set a hostname:

    [stack@director ~]$ sudo hostnamectl set-hostname
    [stack@director ~]$ sudo hostnamectl set-hostname --transient
  3. The director also requires an entry for the system’s hostname and base name in /etc/hosts. The IP address in /etc/hosts must match the address that you plan to use for your undercloud public API. For example, if the system is named and uses for its IP address, then /etc/hosts requires an entry like: manager

4.4. Registering and updating your undercloud

Before installing the director:

  • Register the undercloud using Red Hat Subscription Manager
  • Subscribe and enable the relevant repositories
  • Perform an update of your Red Hat Enterprise Linux packages


  1. Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted:

    [stack@director ~]$ sudo subscription-manager register
  2. Find the entitlement pool ID for Red Hat OpenStack Platform director. For example:

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Subscription Name:   Name of SKU
    Provides:            Red Hat Single Sign-On
                         Red Hat Enterprise Linux Workstation
                         Red Hat CloudForms
                         Red Hat OpenStack
                         Red Hat Software Collections (for RHEL Workstation)
                         Red Hat Virtualization
    SKU:                 SKU-Number
    Contract:            Contract-Number
    Pool ID:             Valid-Pool-Number-123456
    Provides Management: Yes
    Available:           1
    Suggested:           1
    Service Level:       Support-level
    Service Type:        Service-Type
    Subscription Type:   Sub-type
    Ends:                End-date
    System Type:         Physical
  3. Locate the Pool ID value and attach the Red Hat OpenStack Platform 13 entitlement:

    [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
  4. Disable all default repositories, and then enable the required Red Hat Enterprise Linux repositories:

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-13-rpms

    These repositories contain packages the director installation requires.


    Only enable the repositories listed in Section 2.5, “Repository Requirements”. Additional repositories can cause package and software conflicts. Do not enable any additional repositories.

  5. Perform an update on your system to ensure that you have the latest base system packages:

    [stack@director ~]$ sudo yum update -y
  6. Reboot your system:

    [stack@director ~]$ sudo reboot

    The system is now ready for the director installation.

4.5. Installing the director packages

The following procedure installs packages relevant to the Red hat OpenStack Platform director.


  1. Install the command line tools for director installation and configuration:

    [stack@director ~]$ sudo yum install -y python-tripleoclient

4.6. Installing ceph-ansible

The following procedure installs the ceph-ansible package if you plan to create an overcloud with Ceph Storage nodes. If you do not plan to create Ceph Storage nodes in your overcloud, you do not need this package.


  1. Enable the Ceph Tools repository:

    [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms
  2. Install the ceph-ansible package:

    [stack@director ~]$ sudo yum install -y ceph-ansible

4.7. Configuring the director

The director installation process requires certain settings to determine your network configurations. The settings are stored in a template located in the stack user’s home directory as undercloud.conf. This procedure demonstrates how to use the default template as a foundation for your configuration.


  1. Red Hat provides a basic template to help determine the required settings for your installation. Copy this template to the stack user’s home directory:

    [stack@director ~]$ cp \
      /usr/share/instack-undercloud/undercloud.conf.sample \
  2. Edit the undercloud.conf file. This file contains settings to configure your undercloud. If you omit or comment out a parameter, the undercloud installation uses the default value.

4.8. Director configuration parameters

The following is a list of parameters for configuring the undercloud.conf file. Keep all parameters within their relevant sections to avoid errors.


The following parameters are defined in the [DEFAULT] section of the undercloud.conf file:

Defines the fully qualified host name for the undercloud. If set, the undercloud installation configures all system host name settings. If left unset, the undercloud uses the current host name, but the user must configure all system host name settings appropriately.
The IP address defined for the director’s Provisioning NIC. This is also the IP address the director uses for its DHCP and PXE boot services. Leave this value as the default unless you are using a different subnet for the Provisioning network, for example, if it conflicts with an existing IP address or subnet in your environment.
The IP address or hostname defined for director Public API endpoints over SSL/TLS. The director configuration attaches the IP address to the director software bridge as a routed IP address, which uses the /32 netmask.
The IP address or hostname defined for director Admin API endpoints over SSL/TLS. The director configuration attaches the IP address to the director software bridge as a routed IP address, which uses the /32 netmask.
A list of DNS nameservers to use for the undercloud hostname resolution.
A list of network time protocol servers to help synchronize the undercloud’s date and time.

The DNS domain name to use when deploying the overcloud.


When configuring the overcloud, the CloudDomain parameter must be set to a matching value. Set this parameter in an environment file when you configure your overcloud.

List of routed network subnets for provisioning and introspection. See Subnets for more information. The default value only includes the ctlplane-subnet subnet.
The local subnet to use for PXE boot and DHCP interfaces. The local_ip address should reside in this subnet. The default is ctlplane-subnet.
The location and filename of the certificate for OpenStack SSL/TLS communication. Ideally, you obtain this certificate from a trusted certificate authority. Otherwise generate your own self-signed certificate using the guidelines in Appendix A, SSL/TLS Certificate Configuration. These guidelines also contain instructions on setting the SELinux context for your certificate, whether self-signed or from an authority.
Defines whether to generate an SSL/TLS certificate during the undercloud installation, which is used for the undercloud_service_certificate parameter. The undercloud installation saves the resulting certificate /etc/pki/tls/certs/undercloud-[undercloud_public_vip].pem. The CA defined in the certificate_generation_ca parameter signs this certificate.
The certmonger nickname of the CA that signs the requested certificate. Only use this option if you have set the generate_service_certificate parameter. If you select the local CA, certmonger extracts the local CA certificate to /etc/pki/ca-trust/source/anchors/cm-local-ca.pem and adds it to the trust chain.
The Kerberos principal for the service using the certificate. Only use this if your CA requires a Kerberos principal, such as in FreeIPA.

The chosen interface for the director’s Provisioning NIC. This is also the device the director uses for its DHCP and PXE boot services. Change this value to your chosen device. To see which device is connected, use the ip addr command. For example, this is the result of an ip addr command:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:75:24:09 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic eth0
       valid_lft 3462sec preferred_lft 3462sec
    inet6 fe80::5054:ff:fe75:2409/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN
    link/ether 42:0b:c2:a5:c1:26 brd ff:ff:ff:ff:ff:ff

In this example, the External NIC uses eth0 and the Provisioning NIC uses eth1, which is currently not configured. In this case, set the local_interface to eth1. The configuration script attaches this interface to a custom bridge defined with the inspection_interface parameter.

MTU to use for the local_interface.
Path to hieradata override file that configures Puppet hieradata on the director, providing custom configuration to services beyond the undercloud.conf parameters. If set, the undercloud installation copies this file to the /etc/puppet/hieradata directory and sets it as the first file in the hierarchy. See Section 4.9, “Configuring hieradata on the undercloud” for details on using this feature.
Path to network configuration override template. If set, the undercloud uses a JSON format template to configure the networking with os-net-config. This ignores the network parameters set in undercloud.conf. See /usr/share/instack-undercloud/templates/net-config.json.template for an example.
The bridge the director uses for node introspection. This is custom bridge that the director configuration creates. The LOCAL_INTERFACE attaches to this bridge. Leave this as the default br-ctlplane.
A range of IP address that the director’s introspection service uses during the PXE boot and provisioning process. Use comma-separated values to define the start and end of this range. For example,, Make sure this range contains enough IP addresses for your nodes and does not conflict with the range for dhcp_start and dhcp_end.
Defines whether to enable extra hardware collection during the inspection process. Requires python-hardware or python-hardware-detect package on the introspection image.
Runs a set of benchmarks during node introspection. Set to true to enable. This option is necessary if you intend to perform benchmark analysis when inspecting the hardware of registered nodes. See Section 6.2, “Inspecting the Hardware of Nodes” for more details.
Defines whether to support introspection of nodes with UEFI-only firmware. For more information, see Appendix D, Alternative Boot Modes.
Automatically enroll any unknown node that PXE-boots the introspection ramdisk. New nodes use the fake_pxe driver as a default but you can set discovery_default_driver to override. You can also use introspection rules to specify driver information for newly enrolled nodes.
Sets the default driver for automatically enrolled nodes. Requires enable_node_discovery enabled and you must include the driver in the enabled_drivers list. See Appendix B, Power Management Drivers for a list of supported drivers.
Sets the log level of undercloud services to DEBUG. Set this value to true to enable.
Defines whether to update packages during the undercloud installation.
Defines whether to install the validation tools. The default is set to false, but you can can enable using true.
Defines whether to install OpenStack Telemetry services (ceilometer, aodh, panko, gnocchi) in the undercloud. In Red Hat OpenStack Platform, the metrics backend for telemetry is provided by gnocchi. Setting enable_telemetry parameter to true will install and set up telemetry services automatically. The default value is false, which disables telemetry on the undercloud. This parameter is required if using other products that consume metrics data, such as Red Hat CloudForms.
Defines Whether to install the director’s web UI. This allows you to perform overcloud planning and deployments through a graphical web interface. For more information, see Chapter 7, Configuring a Basic Overcloud with the Web UI. Note that the UI is only available with SSL/TLS enabled using either the undercloud_service_certificate or generate_service_certificate.
Defines whether to install the requirements to run validations.
Defines whether to install the novajoin metadata service in the Undercloud.
Defines the one time password to register the Undercloud node to an IPA server. This is required when enable_novajoin is enabled.
Defines whether to use iPXE or standard PXE. The default is true, which enables iPXE. Set to false to set to standard PXE. For more information, see Appendix D, Alternative Boot Modes.
Maximum number of times the scheduler attempts to deploy an instance. Keep this greater or equal to the number of bare metal nodes you expect to deploy at once to work around potential race condition when scheduling.
Defines whether to wipe the hard drive between deployments and after introspection.
A list of hardware types to enable for the undercloud. See Appendix B, Power Management Drivers for a list of supported drivers.
A list of (kernel) architectures that an overcloud will support. Currently this is limited to ppc64le

When enabling support for ppc64le, you must also set ipxe_enabled to False


The following parameters are defined in the [auth] section of the undercloud.conf file:

undercloud_db_password; undercloud_admin_token; undercloud_admin_password; undercloud_glance_password; etc

The remaining parameters are the access details for all of the director’s services. No change is required for the values. The director’s configuration script automatically generates these values if blank in undercloud.conf. You can retrieve all values after the configuration script completes.


The configuration file examples for these parameters use <None> as a placeholder value. Setting these values to <None> leads to a deployment error.


Each provisioning subnet is a named section in the undercloud.conf file. For example, to create a subnet called ctlplane-subnet:

cidr =
dhcp_start =
dhcp_end =
inspection_iprange =,
gateway =
masquerade = true

You can specify as many provisioning networks as necessary to suit your environment.

The gateway for the overcloud instances. This is the undercloud host, which forwards traffic to the External network. Leave this as the default unless you are either using a different IP address for the director or want to directly use an external gateway.

The director’s configuration script also automatically enables IP forwarding using the relevant sysctl kernel parameter.

The network that the director uses to manage overcloud instances. This is the Provisioning network, which the undercloud’s neutron service manages. Leave this as the default unless you are using a different subnet for the Provisioning network.
Defines whether to masquerade the network defined in the cidr for external access. This provides the Provisioning network with a degree of network address translation (NAT) so that it has external access through the director.
dhcp_start; dhcp_end
The start and end of the DHCP allocation range for overcloud nodes. Ensure this range contains enough IP addresses to allocate your nodes.

Modify the values for these parameters to suit your configuration. When complete, save the file.

4.9. Configuring hieradata on the undercloud

You can provide custom configuration for services beyond the available undercloud.conf parameters by configuring Puppet hieradata on the director. Perform the following procedure to use this feature.


  1. Create a hieradata override file, for example, /home/stack/hieradata.yaml.
  2. Add the customized hieradata to the file. For example, add the following to modify the Compute (nova) service parameter force_raw_images from the default value of "True" to "False":

    nova::compute::force_raw_images: False

    If there is no Puppet implementation for the parameter you want to set, then use the following method to configure the parameter:

        value: <parameter_value>

    For example:

        value: 20
        value: 15
  3. Set the hieradata_override parameter to the path of the hieradata file in your undercloud.conf:

    hieradata_override = /home/stack/hieradata.yaml

4.10. Installing the director

The following procedure installs the director and performs some basic post-installation tasks.


  1. Run the following command to install the director on the undercloud:

    [stack@director ~]$ openstack undercloud install

    This launches the director’s configuration script. The director installs additional packages and configures its services to suit the settings in the undercloud.conf. This script takes several minutes to complete.

    The script generates two files when complete:

    • undercloud-passwords.conf - A list of all passwords for the director’s services.
    • stackrc - A set of initialization variables to help you access the director’s command line tools.
  2. The script also starts all OpenStack Platform services automatically. Check the enabled services using the following command:

    [stack@director ~]$ sudo systemctl list-units openstack-*
  3. The script adds the stack user to the docker group to give the stack user has access to container management commands. Refresh the stack user’s permissions with the following command:

    [stack@director ~]$ exec su -l stack

    The command prompts you to log in again. Enter the stack user’s password.

  4. To initialize the stack user to use the command line tools, run the following command:

    [stack@director ~]$ source ~/stackrc

    The prompt now indicates OpenStack commands authenticate and execute against the undercloud;

    (undercloud) [stack@director ~]$

The director installation is complete. You can now use the director’s command line tools.

4.11. Obtaining images for overcloud nodes

The director requires several disk images for provisioning overcloud nodes. This includes:

  • An introspection kernel and ramdisk - Used for bare metal system introspection over PXE boot.
  • A deployment kernel and ramdisk - Used for system provisioning and deployment.
  • An overcloud kernel, ramdisk, and full image - A base overcloud system that is written to the node’s hard disk.

The following procedure shows how to obtain and install these images.

4.11.1. Single CPU architecture overclouds

These images and procedures are necessary for deployment of the overcloud with the default CPU architecture, x86-64.


  1. Source the stackrc file to enable the director’s command line tools:

    [stack@director ~]$ source ~/stackrc
  2. Install the rhosp-director-images and rhosp-director-images-ipa packages:

    (undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa
  3. Extract the images archives to the images directory on the stack user’s home (/home/stack/images):

    (undercloud) [stack@director ~]$ mkdir ~/images
    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
  4. Import these images into the director:

    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/

    This will upload the following images into the director:

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • overcloud-full
    • overcloud-full-initrd
    • overcloud-full-vmlinuz

    The script also installs the introspection images on the director’s PXE server.

  5. To check these images have uploaded successfully, run:

    (undercloud) [stack@director images]$ openstack image list
    | ID                                   | Name                   |
    | 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
    | 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
    | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
    | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
    | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |

    This list will not show the introspection PXE images. The director copies these files to /httpboot.

    (undercloud) [stack@director images]$ ls -l /httpboot
    total 341460
    -rwxr-xr-x. 1 root              root                5153184 Mar 31 06:58 agent.kernel
    -rw-r--r--. 1 root              root              344491465 Mar 31 06:59 agent.ramdisk
    -rw-r--r--. 1 ironic-inspector  ironic-inspector        337 Mar 31 06:23 inspector.ipxe

4.11.2. Multiple CPU architecture overclouds

These are the images and procedures needed for deployment of the overcloud to enable support of additional CPU architectures. This is currently limited to ppc64le, Power Architecture.


  1. Source the stackrc file to enable the director’s command line tools:

    [stack@director ~]$ source ~/stackrc
  2. Install the rhosp-director-images-all package:

    (undercloud) [stack@director ~]$ sudo yum install rhosp-director-images-all
  3. Extract the archives to an architecture specific directory under the images directory on the stack user’s home (/home/stack/images):

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do mkdir $arch ; done
    (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0-${arch}.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0-${arch}.tar ; do tar -C $arch -xf $i ; done ; done
  4. Import these images into the director:

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --http-boot /tftpboot/ppc64le
    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/x86_64/ --http-boot /tftpboot

    This uploads the following images into the director:

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • overcloud-full
    • overcloud-full-initrd
    • overcloud-full-vmlinuz
    • ppc64le-bm-deploy-kernel
    • ppc64le-bm-deploy-ramdisk
    • ppc64le-overcloud-full

      The script also installs the introspection images on the director’s PXE server.

  5. To check these images have uploaded successfully, run:

    (undercloud) [stack@director images]$ openstack image list
    | ID                                   | Name                      | Status |
    | 6d1005ba-ec82-473b-8e33-88aadb5b6792 | bm-deploy-kernel          | active |
    | fb723b33-9f11-45f5-b25b-c008bf509290 | bm-deploy-ramdisk         | active |
    | 6a6096ba-8f79-4343-b77c-4349f7b94960 | overcloud-full            | active |
    | de2a1bde-9351-40d2-bbd7-7ce9d6eb50d8 | overcloud-full-initrd     | active |
    | 67073533-dd2a-4a95-8e8b-0f108f031092 | overcloud-full-vmlinuz    | active |
    | 69a9ffe5-06dc-4d81-a122-e5d56ed46c98 | ppc64le-bm-deploy-kernel  | active |
    | 464dd809-f130-4055-9a39-cf6b63c1944e | ppc64le-bm-deploy-ramdisk | active |
    | f0fedcd0-3f28-4b44-9c88-619419007a03 | ppc64le-overcloud-full    | active |

    This list will not show the introspection PXE images. The director copies these files to /tftpboot.

    (undercloud) [stack@director images]$ ls -l /tftpboot /tftpboot/ppc64le/
    total 422624
    -rwxr-xr-x. 1 root   root     6385968 Aug  8 19:35 agent.kernel
    -rw-r--r--. 1 root   root   425530268 Aug  8 19:35 agent.ramdisk
    -rwxr--r--. 1 ironic ironic     20832 Aug  8 02:08 chain.c32
    -rwxr--r--. 1 ironic ironic    715584 Aug  8 02:06 ipxe.efi
    -rw-r--r--. 1 root   root          22 Aug  8 02:06 map-file
    drwxr-xr-x. 2 ironic ironic        62 Aug  8 19:34 ppc64le
    -rwxr--r--. 1 ironic ironic     26826 Aug  8 02:08 pxelinux.0
    drwxr-xr-x. 2 ironic ironic        21 Aug  8 02:06 pxelinux.cfg
    -rwxr--r--. 1 ironic ironic     69631 Aug  8 02:06 undionly.kpxe
    total 457204
    -rwxr-xr-x. 1 root             root              19858896 Aug  8 19:34 agent.kernel
    -rw-r--r--. 1 root             root             448311235 Aug  8 19:34 agent.ramdisk
    -rw-r--r--. 1 ironic-inspector ironic-inspector       336 Aug  8 02:06 default

The default overcloud-full.qcow2 image is a flat partition image. However, you can also import and use whole disk images. See Appendix C, Whole Disk Images for more information.

4.12. Setting a nameserver for the control plane

If you intend for the overcloud to resolve external hostnames, such as, it is recommended to set a nameserver on the overcloud nodes. For a standard overcloud without network isolation, the nameserver is defined using the undercloud’s control plane subnet. Use the following procedure to define nameservers for the environment.


  1. Source the stackrc file to enable the director’s command line tools:

    [stack@director ~]$ source ~/stackrc
  2. Set the nameservers for the ctlplane-subnet subnet:

    (undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet

    Use the --dns-nameserver option for each nameserver.

  3. View the subnet to verify the nameserver:

    (undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet
    | Field             | Value                                         |
    | ...               |                                               |
    | dns_nameservers   |                                       |
    | ...               |                                               |

If you aim to isolate service traffic onto separate networks, the overcloud nodes use the DnsServers parameter in your network environment files.

4.13. Next Steps

This completes the director configuration and installation. The next chapter explores basic overcloud configuration, including registering nodes, inspecting them, and then tagging them into various node roles.