Install OpenStack on Ubuntu 26.04 / 24.04 with DevStack

One git clone, a seven-line config file and about twelve minutes of stack.sh. That is all it takes to install OpenStack on Ubuntu with DevStack and boot a real instance with a floating IP. The hard part is knowing which defaults bite: a first-boot package lock that kills the run in six seconds, and a bridge address that vanishes after every reboot.

Original content from computingforgeeks.com - post 12134

This guide covers the full DevStack deployment on Ubuntu: the stack user, local.conf, the install run, verifying Nova and Neutron from the OpenStack CLI, launching a CirrOS instance, logging in to the Horizon dashboard, and keeping floating IPs alive across reboots. Every command below was run in October 2026 against the OpenStack 2026.2 (Hibiscus) branch of DevStack, on Ubuntu 26.04 LTS and Ubuntu 24.04 LTS.

DevStack is a developer and test environment. It runs every service from git checkouts under one user, and it is not built to be upgraded or kept alive for months. For a cloud that has to stay up, use Kolla-Ansible instead, as in the Kolla-Ansible deployment on Debian.

What you need to install OpenStack on Ubuntu

A fresh Ubuntu 26.04 or 24.04 server with a static IP. Don’t run DevStack on a machine you care about. It installs a large set of system packages, rewrites Open vSwitch and creates its own bridges.

Sizing is driven by two things: the control plane, and the instances you plan to boot. Right after install, the control plane alone used about 6 GB of RAM on our test boxes. MariaDB, the uWSGI API workers and the Neutron OVN workers account for most of that. Every instance you launch adds the RAM of its flavor on top. Our lab ran 6 vCPU, 16 GB RAM and a 100 GB disk, which left room for a handful of small instances. Treat 8 GB as the floor to get through stack.sh, not a working target. Disk use after install was 8.5 GB, plus a sparse 30 GB loop file that Cinder uses as its LVM backing store.

Instances need hardware virtualization. On bare metal that is a BIOS setting. Inside a VM, the hypervisor must pass it through (on Proxmox, set the CPU type to host; on plain KVM, follow the nested virtualization guide). Check that the CPU flags are visible:

grep -cE 'vmx|svm' /proc/cpuinfo

Any number above zero means KVM acceleration is available. On Intel, recent kernels print two matching lines per vCPU (flags and vmx flags), so our 6 vCPU guest reported twice its core count. AMD hosts show one line per vCPU:

12

With a zero here, DevStack still installs, but Nova falls back to plain QEMU emulation and instances crawl.

Wait for the first-boot updates

This catches almost everyone on a fresh cloud image. In the first minutes after boot, cloud-init and the Ubuntu apt timers run their own apt-get, which holds the dpkg lock. Our first stack.sh run on Ubuntu 26.04 died after 6.3 seconds when it tried to install Python headers:

Error: “E: Unable to acquire the dpkg frontend lock”

These are the exact lines from the failed run:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1933 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
+ functions-common:apt_get:1211            :   result=100

The fix is to wait, not to kill apt. Let cloud-init finish, then block until nothing holds the lock:

cloud-init status --wait
while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do sleep 10; done

When the loop returns, the box is free. The rerun after this went through cleanly. Make sure git is present too, since some minimal images leave it out (our 24.04 test image did):

sudo apt update && sudo apt install -y git

Create the stack user

DevStack refuses to run as root. It expects a dedicated user with passwordless sudo, and its home in /opt/stack, where every service checkout lands:

sudo useradd -s /bin/bash -d /opt/stack -m stack
sudo chmod +x /opt/stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack

The chmod +x matters. Ubuntu creates home directories with mode 750 (HOME_MODE in /etc/login.defs), and other service accounts need to traverse /opt/stack to reach the checkouts. Switch to the new user for everything that follows:

sudo -u stack -i

Clone the DevStack branch

Clone a stable branch, never master. A stable branch pins every OpenStack service to the same release, so Nova, Neutron and Keystone all come from one coordinated release. Master changes daily and breaks without warning:

git clone https://opendev.org/openstack/devstack -b stable/2026.2 #https://releases.openstack.org/
cd devstack

This branch officially supports Ubuntu 26.04 (resolute), Ubuntu 24.04 (noble), Debian 13 and 12, and RHEL 9 and 10 clones. The list lives in the SUPPORTED_DISTROS line of stack.sh. On any other release the script prints a warning and stops, telling you to rerun it as FORCE=yes ./stack.sh.

Write local.conf

DevStack reads its settings from local.conf in the checkout. A minimal file is enough. Create it:

vim local.conf

Paste this, setting HOST_IP to the address of your server and picking a real password:

[[local|localrc]]
ADMIN_PASSWORD=StackLab2026
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
HOST_IP=10.0.1.50
LOGFILE=/opt/stack/logs/stack.sh.log

That is the exact file we ran, with the lab IP swapped out. Everything else stays at the DevStack defaults: Keystone, Glance, Nova, Placement, Neutron with OVN, Cinder on an LVM loop file, and Horizon. Setting HOST_IP explicitly avoids the classic failure on hosts with more than one interface, where DevStack guesses the wrong address and binds every endpoint to it.

Run stack.sh

Run it inside tmux or screen. A dropped SSH session halfway through leaves a half-built cloud that is faster to rebuild than to repair:

./stack.sh

The script clones each service, builds a Python virtualenv in /opt/stack/data/venv, creates the databases and registers the endpoints. It ends with a summary like this one from the Ubuntu 26.04 box:

This is your host IP address: 10.0.1.50
This is your host IPv6 address: ::1
Horizon is now available at http://10.0.1.50/dashboard
Keystone is serving at http://10.0.1.50/identity/
The default users are: admin and demo
The password: StackLab2026

Services are running under systemd unit files.
For more information see:
https://docs.openstack.org/devstack/latest/systemd.html

DevStack Version: 2026.2
Change: 0fb9685c1bf22cd0b4d576d7a74f64195ad934fe cinder: Install dependencies for backup drivers 2026-09-24 08:55:03 +0000
OS Version: Ubuntu 26.04 resolute
real	12m9.811s

Twelve minutes on 26.04 and fourteen and a half on 24.04, on the same hardware and network. Most of that time is package downloads and pip installs, so a slow mirror stretches it. Every service now runs as a systemd unit named devstack@<service>. Twenty of them were active after install:

systemctl list-units "devstack@*" --no-legend --plain | wc -l

Logs for any of them come from sudo journalctl -u devstack@n-cpu (swap in the unit name you need). The stack user is not in the journal groups, so keep the sudo.

Verify OpenStack from the CLI

DevStack drops an openrc file in the checkout that exports the right credentials. Source it as the admin user:

source ~/devstack/openrc admin admin

Then check the client version, the Nova services and the Neutron agents:

openstack --version
openstack compute service list -c Binary -c Host -c State
openstack network agent list -c "Agent Type" -c Host -c Alive -c State

Every Nova service should read up, and both OVN agents should be alive:

Neutron now ships an “OVN Neutron agent” next to the OVN controller gateway agent. That is expected on this release and not a leftover from the old Open vSwitch agent. If you have not used the unified client much, the OpenStack client guide covers installing it on a separate workstation.

Launch the first instance

DevStack creates a demo project with a private tenant network, a router, and a public network on 172.24.4.0/24 that the host can reach directly. Work as the demo user:

source ~/devstack/openrc demo demo

Create an SSH key, register it as a keypair, and open ICMP and SSH in the default security group. The keypair guide has more options if you manage several keys:

ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519 -q
openstack keypair create --public-key ~/.ssh/id_ed25519.pub demo-key
openstack security group rule create --proto icmp default
openstack security group rule create --proto tcp --dst-port 22 default

Boot a CirrOS instance on the private network. DevStack already uploaded the CirrOS image and created the m1.tiny flavor:

openstack server create --flavor m1.tiny --image cirros-0.6.3-x86_64-disk \
  --network private --key-name demo-key --wait vm01

With KVM available, --wait returned ACTIVE in 6.6 seconds on 26.04 and 6.7 seconds on 24.04. Allocate a floating IP from the public network and attach it:

FIP=$(openstack floating ip create public -f value -c floating_ip_address)
openstack server add floating ip vm01 "${FIP}"
openstack server list -c Name -c Status -c Networks
ping -c3 "${FIP}"

The instance carries its private, floating and IPv6 addresses, and the floating IP answers from the host:

SSH in as the cirros user with the key you registered. Floating IPs get recycled in a lab, so skip the host key prompt for this throwaway instance:

ssh -o StrictHostKeyChecking=no cirros@"${FIP}" uname -a

On Ubuntu 26.04 the login works, but the newer OpenSSH client warns about the key exchange first. CirrOS runs Dropbear, which has no post-quantum key exchange. The warning is harmless on a test instance, and Ubuntu 24.04 does not print it:

Warning: Permanently added '172.24.4.217' (ED25519) to the list of known hosts.
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Linux vm01 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 GNU/Linux

For anything beyond CirrOS, build your own tenant networks with the networks and subnets walkthrough, or attach block storage with Cinder volumes.

Log in to the Horizon dashboard

Horizon is served by Apache at http://10.0.1.50/dashboard. Use your own HOST_IP. Log in as admin or demo with the ADMIN_PASSWORD from local.conf. The demo project overview shows the instance, the floating IP and the quota use:

Under Compute, the Instances page lists vm01 with its addresses, the key pair and the power state:

Network Topology is the quickest way to see how DevStack wired things: the public network, router1, the shared network and the private network with the instance attached:

From here, the same cloud works as a target for automation. The Terraform instance deployment guide runs unchanged against a DevStack endpoint.

Ubuntu 26.04 vs 24.04 with DevStack

Both releases installed the same OpenStack code from the same DevStack commit. The differences are in the base system:

Measured	Ubuntu 26.04 LTS	Ubuntu 24.04 LTS
stack.sh run time	12m 10s	14m 36s
Host Python used for the venv	3.14	3.12
Kernel	7.0	6.8
RAM used after install	6.2 GB	5.7 GB
OpenStack client	10.3.0	10.3.0
Nova / Neutron / Keystone	34.0 / 29.0 / 30.0	34.0 / 29.0 / 30.0
First instance ACTIVE	6.6 s	6.7 s
Post-quantum SSH warning to CirrOS	Yes (OpenSSH 10.2)	No

Pick 26.04 for a new lab. Pick 24.04 when the DevStack box has to match production hosts that are still on it. No command in this guide changes between the two.

Make DevStack survive a reboot

DevStack has a reputation for not surviving reboots. On this release it mostly does. After a reboot, all twenty devstack@ units came back active, and the Cinder loop device re-attached. Two things did not come back.

The first is the instance itself. Nova leaves it SHUTOFF, so start it again with openstack server start vm01. The second is worse because it fails silently. The br-ex bridge loses the 172.24.4.1 gateway address DevStack gave it, so every floating IP stops answering while OpenStack reports everything healthy. Re-adding the address brings traffic straight back. DevStack also puts the IPv6 public gateway and an IPv6 route on br-ex, and those are lost too. The fix below restores IPv4 only, which is all the floating IP flow in this guide uses:

To make it permanent, add a small systemd unit that restores the address at boot:

sudo vim /etc/systemd/system/devstack-br-ex.service

Add the following. The address and prefix match the default DevStack public network, so change them if you set FLOATING_RANGE or PUBLIC_NETWORK_GATEWAY in local.conf:

[Unit]
Description=Restore DevStack br-ex gateway address
After=ovs-vswitchd.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ip link set br-ex up
ExecStart=/usr/sbin/ip addr replace 172.24.4.1/24 dev br-ex
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable it:

sudo systemctl daemon-reload
sudo systemctl enable devstack-br-ex.service

We rebooted the 26.04 box with the unit in place. br-ex came up with 172.24.4.1/24 on its own, and after openstack server start vm01 the floating IP answered with 0% packet loss. Keep a DevStack VM disposable anyway: snapshot it at the hypervisor once it works, and roll back to the snapshot rather than debugging a broken stack in place.