Search
Close this search box.
OpenStack installation on Ubuntu

OpenStack installation on Ubuntu

Quickly install OpenStack with DevStack on an Ubuntu 22.04 machine  

The objective of this workshop is to install a personal OpenStack lab on a single PC, running Ubuntu Server 22.04. We will install OpenStack, start a virtual machine, and enter the virtual machine over SSH. Next, we download an image from the internet and use that to start a virtual machine and install and update packages on that machine. We will use the DevStack scripts to do the heavy lifting.  

Prerequisites  

Your lab machine will be used to experiment, to try things out and to learn. For this to be fun, you want a snappy lab machine which is a joy to use. Use a workable machine, with at least a 6th generation CPU and minimal 8 GB RAM. The more RAM the better. Make sure your machine has enough disk space, 30 GB or more.  

DevStack makes a lot of changes to your system, don’t use a system that is already in use. To prevent any problems while setting the configuration, it is best to use a clean system.  

We start by doing a fresh installation of Ubuntu, overwriting anything that is stored on the disks, so make sure you haven’t any valuable data on the machine.  

DevStack  

Our goal is to set up a machine running OpenStack. DevStack is a set of scripts and utilities to quickly deploy an OpenStack cloud from Git source trees.  

The DevStack scripts will do the installation and configuration to jump start your OpenStack installation.  

Ubuntu Server  

We begin with a fresh installation of the latest LTS-version of Ubuntu Server, in our case Ubuntu Server 22.04 LTS.  

A fresh installation assures that we start with a clean slate, to give the DevStack scripts the opportunity to do their magic. A clean slate prevents the scripts running into problem with an existing configuration, e.g., an already configured MySQL-server.  

We use Ubuntu Server, and not a desktop version, to prevent issues with the networking configuration.  

  • Install Ubuntu Server, using the default settings. Choose “set up this disk as an LVM group” (logical volume manager) for the file system and not e.g., ZFS. 
  • Set up the system with a static IP address.  
  • Run apt upgrade.  

After this, we can use this machine as a headless system, using the command line over SSH.  

Create a dedicated user  

Create a dedicated user “stack” and grant sudo privileges. We set up the home directory in /opt/stack, and make sure this directory is world readable, so Apache can access the files.  

sudo useradd -s /bin/bash -d /opt/stack -m stack
echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers #as root 
sudo chmod +x /opt/stack

Clone the DevStack Git repo  

We now switch to the newly created user and get the latest version of the DevStack scripts from the Git repository.  

sudo -u stack -i
git clone https://git.openstack.org/openstack-dev/devstack
cd devstack

Create the local.conf file  

We create a configuration file, that will define how the DevStack scripts do their work.  

You must determine if you are going to use one or two network interfaces. With two network interfaces, one interface is for the system administration, the other interface lets the virtual machines connect to the world outside your lab machine. When you have only one interface, you use it for both with some additional routing.

In this workshop, we focus on a setup with just one network interface, because most PC’s have one NIC.  

As the user “stack”, create the file ~/devstack/local.conf with the following contents:

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
IP_VERSION=4
LOGFILE=$DEST/logs/stack.sh.log
LOG_COLOR=False

Select a more secure password. Only use alphanumeric characters in your password, as some services fail to work when using special characters.  

You can find an example for the configuration file in devstack/samples.  

Start the DevStack scripts  

Make sure your machine has the right ip address before you continue. Changing the ip address after running the stack.sh script will result in a lot of configuration errors.  

Now that we have the scripts and the config file in place, we can start the scripts. Depending on your internet connection and the performance of your lab machine, this can take quite some time.  

Get a nice cup of your favourite warm or cold beverage, sit back, and let the scripts run.  

./stack.sh

Source openrc  

We proceed after the installation scripts of OpenStack are finished.  

We do this as the user “stack”, and first import some settings in our shell, by sourcing the file “openrc” into it. This file is in the devstack directory, the same place where we just created the local.conf and ran the stack.sh script.  

source openrc

Source openrc every time you reconnect.  

Allow login over SSH  

We change a security setting to allow us to ping and access the VM’s over SSH.  

openstack security group rule create --proto icmp --dst-port 0 default
openstack security group rule create --proto tcp --dst-port 22 default

Create floating ip addresses  

We create some floating ip addresses, which we later assign to our VM’s.  

openstack floating ip create public

Repeat this command a few times to create more floating ip’s. To list the ip’s that we have created: 

openstack floating ip list

Access the web interface  

Go to http://<ip-address> in the web browser on your local workstation or laptop, and check that you can access the dashboard.  

DevStack has created two user accounts, “admin”, and “demo”. Both use the password you have set in the local.conf. Test that you can log in with these credentials.  

Add an SSH-key  

Cloud-images, like the cloud-image for Ubuntu and Debian, often support “cloud-init”. This allows, among other things, password-less log in over SSH. To be able to use this, upload one or more SSH public key files.  

In the web browser, open Compute-Key Pairs. Click on the button “Import Public Key” to import a public key.  

Launch image  

The install script added a tiny image with the Cirros OS. We are going to launch this image to create an instance and associate a floating ip with it.  

In the web browser, select the project “demo” in the top lefthand corner. Open Compute-Images and hit the button “Launch” at the line with the Cirros image. This will open a new window, with the names of the tabs in the left column in a blue font. An asterisk after the name of the tab indicates that additional configuration is required.  

  • In the details tab, provide a name and a description.  
  • In the flavor tab, select a flavor, in this case cirros256.  
  • In the networks tab, select the private subnet.  

The other tabs we leave as is and hit the blue “Launch instance” button. This will add the job to launch the instance to the queue.  

Now go to Compute-Instances and check that the instance has the state “Running”.  

Associate a floating ip address  

Next, we go to Network-Floating IP’s.  

On the line with a floating ip, hit the button “Associate”. This opens a new window. In the selectbox “Ports to be associated” select the line with the name of the Cirros instance.  

Test that you can log in over SSH, with the username “cirros” and the SSH-key of which we have uploaded the public key.  

First, do this from the DevStack machine.  

Next, on your workstation or laptop create a route to the 172.24.4.0/24 network, with the ip address of your DevStack machine as the gateway. You should now be able to log in over SSH from your local workstation or laptop.  

In the web browser, open Compute-Instances, and shutdown the Cirros instance and delete it.  

Import an image  

Next, we will download a Debian cloud-image from http://cdimage.debian.org/images/cloud. Make sure the user “stack” can read this image file. Below is the command to import the image into OpenStack. 

openstack image create \
--container-format bare \
--disk-format qcow2 \
--property hw_disk_bus=scsi \
--property hw_scsi_model=virtio-scsi \
--property os_type=linux \
--property os_distro=debian \
--property os_admin_user=debian \
--property os_version='10.9.1' \
--private \
--file debian-12-genericcloud-amd64-20230612-1409.qcow2 debian-cloud-image

The command above ends with the file name of the image and a name for the image, that will be shown in the web interface, so you can recognize it.  

Check that you can see the image in the web browser, in Compute-Images. Launch the image like we did with the Cirros image, but select a larger flavor, e.g., “ds512M”. Again, associate a floating ip with it.  

Check that you can log in over SSH, this time with the user “debian”.  

DevStack has set up NAT to let your VM’s connect to the world outside your lab machine. Check the nameserver settings in /etc/resolv.conf in the VM and install and update some packages from the internet.  

Prepare to restore network settings  

At the time of writing, the DevStack scripts omit to create a persistent configuration for the ipv4 public addresses. After a reboot, the ipv4 address of the bridge br-ex is lost, as well as the masquerading settings (NAT) in iptables. We expect this will be solved in the future, but for now you must do some additional work.  

Do this before you reboot the machine.  

Install the Ubuntu package iptables-persistent, this will keep the iptables settings persistent, including the masquerading rules.  

sudo apt install iptables-persistent

The installation script will ask you if you want to save the current rules for ipv4 and for ipv6. Say “yes” both times.  

Restore ip address of bridge after reboot  

After a reboot, the ipv4 address of the bridge br-ex is lost. The following commands restore the ip address and the route.  

sudo ip addr add 172.24.4.1 dev br-ex
sudo ip link set br-ex up
sudo ip route add 172.24.4.0/24 via 172.24.4.1

With the persistent iptables masquerading rules and the restored ipv4 settings of br-ex, the instances will keep their access to the world outside the lab machine.  

Wrap up  

With the help of the DevStack scripts we have installed OpenStack on a PC with a single NIC. We have downloaded some images and created and destroyed VM’s (instances) based on these images. The VM’s can be accessed from hosts in the local network, with proper routing on those hosts, and the VM’s can install and update packages from the internet.  

You have successfully set up a personal OpenStack lab. More questions? Feel free to reach out to us through the contact form or give us a call. 

We are hiring!
Are you our new