How to install Red Hat Openstack 9 with Packstack


Here is an updated version of how to install Red Hat Openstack 9 (Mitaka) with Packstack and perform some common basic configuration changes. The same procedure could be used with RDO if you don’t have subscriptions for Red Hat Openstack. Obviously, the main differences would be that you would use CentOS instead of RHEL, and configure different repos.

Packstack is a simple tool to quickly install Red Hat Openstack in an non-HA configuration.   Where OSP Director would be the appropriate tool for a full HA environment with complete lifecycle capabilities.

Pre-requisites before staring the install:

  • Basic RHEL7 installation
  • Valid Openstack subscription attached to this server
  • Following repos:
    • rhel-7-server-rpms
    • rhel-7-server-extras-rpms
    • rhel-7-server-rh-common-rpms
    • rhel-7-server-optional-rpms
    • rhel-7-openstack-9-tools-rpms
    • rhel-7-openstack-9-rpms
    • rhel-7-openstack-9-optools-rpms
subscription-manager register --username='your_username' --password='your_password'
subscription-manager attach --pool=your_pool_id
subscription-manager repos --disable=*
subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-openstack-9-rpms --enable=rhel-7-server-optional-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-7-server-openstack-9-optools-rpms --enable=rhel-7-server-openstack-9-tools-rpms


  • Stop and Disable SELINUX
  • Stop and Disable Firewalld
  • Stop and Disable NetworkManager
  • Make sure you have static IPs on your NICs, not DHCP based.
  • Make sure Hostname and DNS are setup appropriately.  Your hostname should resolve.  Put it in /etc/hosts if required.
  • Update to latest packages (yum -y update) and reboot.

Installing packstack

yum install -y openstack-packstack

Once packstack is installed, you can simply do “packstack –all-in-one” as described in most instructions you will find online.  This is just the simplest way to install with packstack, using default configuration for everything.  That said, in my example here, I want to make some changes to the default config.   So here is usually what I will do:

packstack --gen-answer-file=/root/answers.txt

This will create an answer file with all configuration settings.   I can now change all the settings I want in this file, and then launch packstack again using this file as configuration input.

Here are all the changes I will do in my answer file:

# turning "ON" heat module.  Heat is great! :-)

# also turning "ON" LBaaS.  

# By default, Neutron only allows vxlan networks.
# But I want "flat" and "local" drivers to be there as well.
# (will be required later to create new networks)

# These lines will automatically create an OVS bridge for me.
# This is required by Neutron to get external access.
# Replace "eth0" by the name of your interface

# By default packstack install some demo stuff.  
# Turning this OFF.

The “flat” driver and the OVS bridge configuration is usually where people struggle at first.  Regardless of how we will configure our external networks later (and I’ll talk of tenant vs provider networks later), we will need to create a “flat” network to get outside of Openstack.  VXLAN packets would have no where to go on my network.  Also, an OVS bridge must exist for Neutron to do his job.   The “BRIDGE_MAPPING” and “BRIDGE_IFACES” configuration lines will take care of this automatically for you.

Installing Openstack

Ok, now that packstack is installed and we have an answer file.  Let’s start the installation:

packstack --answer-file=/root/answers.txt

This could take some time to complete based on how fast is your network and access to the RPMS.

Finalizing the configuration of Openstack

You can first check that all openstack services are running:

openstack-service status

You should also see a KeystoneRC file in your root folder:  /root/keystonerc_admin

Source this file to get access to your Openstack cloud:

source /root/keystonerc_admin

At this point, I usually create myself an account with my own password.   *this is an optional step:

openstack user create --project admin --password <password> <username>
openstack role add --user <username> --project admin admin

This way, you can log into Horizon (web portal) using your own credentials instead of using the admin account automatically generated password.

You could also create a new KeystoneRC file with your own credentials for when you are in command line.  Again, optional step!

At least one image in Glance will be required before we can launch anything.  Let’s just upload a small Cirros image for now (ideal for testing as it’s tiny and fast!).

curl -o /root/cirros.img
glance image-create --name='cirros' --container-format=bare --disk-format=qcow2 < /root/cirros.img

Finally, Before you can launch instances (VMs), you must finalize your tenant network configuration:  create at least one network for VMs to boot on.  There is two very common ways to deal with networks in Openstack:  tenant networks vs provider networks.

When using tenant networks, your instances would boot up on a virtual network (usually based on VXLAN) and would require to go trough a virtual Openstack router to get access to the outside world.   To allow access from the outside to the internal virtual network, you would create floating IPs on your virtual router.  The is the most classic way to deploy Openstack.

When using provider networks, you can allow your instances to boot up directly on the external (or public) network.  No need for virtual networks, no need for floating IPs.    This is a much easier way to deal with networks, can provide better performance (no VXLAN encapsulation), but obviously doesn’t scale as much from an IP allocation perspective as each instance will require at least one public IP.

Configuring tenant networks

I first need to create an external (public) network where floating IPs will be assigned:

neutron net-create public --router:external True --provider:physical_network ex-net --provider:network_type flat --tenant-id services

neutron subnet-create public --name public --allocation-pool start=,end= --disable-dhcp --gateway=

A few things to note here:  

  • This will only work if I have allowed “flat” network drivers in my answers.txt file.  If I haven’t done that, I will need to update neutron manually to allow “flat” driver and restart neutron:  vi /etc/neutron/plugin.ini;  openstack-service restart neutron
  • “ex-net” is the name of the physical network (physnet) I used in my answer file.  This is important that you keep the same name.  Openstack doesn’t attach to a physical interface name like “eth0”, instead we use an alias called “physnet”.   This way, multiple servers in our stack could have different physical interface names, but always use the same alias.
  • I have created by public network under my “services” tenant.  But all tenants will see this network.
  • Obviously, change the public subnet configuration to what make sense for you.   Floating IPs will be allocated in the allocation-pool range define by this subnet.

Now, in a tenant network configuration, I need to create at least one router and a private (VXLAN based) network for my instances to boot on:

neutron router-create router
neutron router-gateway-set router public
neutron net-create private
neutron subnet-create private --name private --gateway --enable-dhcp --dns-nameserver
neutron router-interface-add router private

We should be all good now, let’s boot our first instance on our private network:

nova boot --flavor m1.tiny --image cirros cirros01

Log into horizon, you should see your cirros image and have access to the cirros console.   Update your security groups to allow SSH and assign a floating IP if you’d like to connect to is remotely.

Configuring provider networks

Let’s now see how we can avoid using floating IPs, routers and virtual networks.    In many cases, it make sense to just boot up Openstack instances on an existing physical network (provider network).

To do that, you need to first rollback all the configuration you did to create tenant networks in the previous step.   You could also have a mix of tenant and provider networks if you have other network interfaces configured on your Openstack servers.  That said, the following instructions will assume that you rollbacked all previous configuration and are using the same “eth0 => ex-net => br-ex” configuration.

When an instance is booting up, the instance reaches out to the metadata service to get configuration details.   As an example, if you launch this curl request from an Openstack instance, you will get your hostname back:

# curl

What you need to understand before moving to provider networks is how your instances get network access to the IP address (metadata service).  By default, the virtual router (your instance default gateway), has a route to this metadata service IP.   But when using provider networks, you don’t have this virtual router anymore.   For this reason, you need to change your DHCP agent configuration so that a route is injected into your instance during the DHCP process and your dnsmasq DHCP server will then also route your instances metadata HTTP requests to your metadata server.

# Change the following settings in dhcp_agent.ini
vi /etc/neutron/dhcp_agent.ini


# Restart Neutron
openstack-service restart neutron

Now, all I am missing is to create a new public network (provider network) under your tenant allowing him to boot instances directly on this network.

# Get your tenant (project) ID 
openstack project list

# Create a new network under this tenant ID
neutron net-create public --provider:physical_network ex-net --provider:network_type flat --tenant-id e4455fcc1d82475b8a3a13f656ac701f

# Create a subnet for this network
neutron subnet-create public --name public --allocation-pool start=,end= --gateway=

Now, boot an instance:

nova boot --flavor m1.tiny --image cirros cirros01