How to Install OpenStack

Plan Hardware and Networking

The minimum hardware for a functional OpenStack lab is a single server with at least 16 GB of RAM, a multi-core CPU with hardware virtualization extensions enabled in BIOS (Intel VT-x or AMD-V), 100 GB of SSD storage, and one network interface. This single-node setup uses DevStack or MicroStack and is suitable only for evaluation and learning.

A production deployment requires a minimum of three servers: one controller node (running the API services, database, message queue, and dashboard), and two or more compute nodes (running the Nova compute service and the KVM hypervisor). The controller node needs at least 32 GB of RAM, 8 CPU cores, and fast SSD storage for the database. Compute nodes should have as much RAM and as many CPU cores as your VM workloads demand, because these resources are directly allocated to VMs.

Networking is the most critical planning step. Production OpenStack deployments typically use three separate networks. The management network carries API traffic, database replication, and message queue communication between services. The tunnel network (also called the overlay network) carries encapsulated VM-to-VM traffic using VXLAN or GRE tunnels. The provider network connects VMs to the external physical network for internet access and incoming connections. Each network should use a separate physical or VLAN-tagged interface on each server. Mixing these networks on a single interface works for testing but creates security and performance problems in production.

Document your network plan before starting: IP ranges for each network, VLAN IDs if applicable, gateway addresses, DNS servers, and the IP allocation ranges that OpenStack will use for floating IPs (public-facing addresses assigned to VMs). Networking misconfigurations are the single most common cause of failed OpenStack deployments.

Choose a Deployment Method

DevStack is the official development and testing installation tool. It runs a shell script that installs all OpenStack services from source (Git repositories) on a single machine, creating a fully functional but non-production environment. DevStack is useful for learning OpenStack, testing new features, and developing applications against the OpenStack APIs. It should never be used for production because it installs from development branches, does not configure high availability, and is designed to be disposable (reinstall from scratch rather than upgrade).

Kolla-Ansible is the recommended deployment tool for production environments. It deploys each OpenStack service as a Docker container, managed by Ansible playbooks. This containerized approach isolates services from each other and from the host operating system, making upgrades cleaner (replace containers rather than updating packages in place) and troubleshooting simpler (restart or rebuild individual containers without affecting others). Kolla-Ansible supports multi-node deployments with high availability, Ceph integration, and TLS encryption for all services.

MicroStack (from Canonical) packages OpenStack as a snap, a self-contained package that includes all dependencies. MicroStack installs with a single command and provides a functional OpenStack environment suitable for edge computing deployments, small-scale private clouds, and organizations that want OpenStack without the complexity of a full Kolla-Ansible deployment. MicroStack supports multi-node clustering and is designed to be manageable by a single administrator.

Commercial distributions from Canonical (Charmed OpenStack), Red Hat (Red Hat OpenStack Platform), and SUSE include their own deployment tools, tested package sets, and enterprise support contracts. These are appropriate for organizations that need vendor-backed SLAs and do not want to manage community OpenStack themselves.

Prepare the Operating System

Most deployment tools require a clean installation of Ubuntu Server (22.04 LTS or 24.04 LTS) or CentOS Stream / Rocky Linux on each server. Install the minimal server configuration without a graphical desktop, as OpenStack servers are managed entirely through SSH and web interfaces.

After installation, update all packages to the latest versions and reboot to apply any kernel updates. Configure static IP addresses on all network interfaces according to your network plan. Set the hostname on each server to a meaningful name (controller, compute01, compute02) and ensure all servers can resolve each other's hostnames through DNS or /etc/hosts entries. Disable swap on all servers, as both OpenStack services and KVM perform better with swap disabled, and unexpected swapping can cause service timeouts.

Ensure SSH key-based authentication is configured between the deployment host (the machine where you run Kolla-Ansible) and all target servers. The deployment tools use SSH to configure remote hosts and will fail if password-based authentication is required. Create a dedicated user for deployment (such as "kolla" or "stack") with passwordless sudo access on all servers.

Verify that hardware virtualization is enabled by checking for the vmx (Intel) or svm (AMD) flags in /proc/cpuinfo on each compute node. If these flags are absent, enable virtualization in the server's BIOS/UEFI settings. Without hardware virtualization, KVM falls back to software emulation, which is too slow for production workloads.

Run the Deployment

For a DevStack installation, clone the DevStack repository, create a local.conf configuration file specifying passwords, network interfaces, and which services to enable, and run the stack.sh script. The script takes 20 to 40 minutes depending on hardware and network speed, and produces a complete OpenStack environment with Horizon accessible at the server's IP address.

For a Kolla-Ansible deployment, the process involves several stages. First, install Kolla-Ansible and its dependencies (Python, Ansible, Docker) on the deployment host. Then configure two files: the Ansible inventory (which maps servers to roles like controller, compute, network, storage) and globals.yml (which sets configuration options like the OpenStack release, network interfaces, storage backend, TLS settings, and enabled services). Run kolla-ansible bootstrap-servers to prepare all target hosts, then kolla-ansible prechecks to validate the configuration, and finally kolla-ansible deploy to roll out all services. The deployment creates Docker containers for each service, configures networking between them, initializes databases, and creates service endpoints in Keystone.

After deployment, run kolla-ansible post-deploy to generate the admin credentials file (admin-openrc.sh), which sets environment variables for authenticating with the OpenStack CLI tools. Source this file in your shell to start interacting with the cloud through the openstack command-line client.

Verify and Configure Services

Access the Horizon dashboard by navigating to the controller's IP address in a browser. Log in with the admin credentials generated during deployment. The dashboard should show all enabled services in a healthy state. If any service shows as down, check the container logs on the relevant host using docker logs followed by the container name.

Create a test project and user to verify multi-tenant functionality. Switch to the test user's context and perform the following operations to verify each layer of the stack works correctly. Upload a cloud image (Ubuntu cloud images or CirrOS for lightweight testing) to Glance. Create a private network and subnet with a router connected to the external provider network. Define security groups that allow SSH and ICMP traffic. Launch a VM instance from the uploaded image on the private network. Allocate and associate a floating IP to the instance. Verify you can ping the floating IP and SSH into the instance from outside the cloud.

If the VM launches but is unreachable, the problem is almost always networking. Check that the provider network bridge is correctly mapped to the physical interface, that the external network's IP range does not conflict with your existing network, and that the router between the private and external networks has the correct gateway set. Use the openstack server console-url command to access the VM's console if network connectivity fails, which helps determine whether the problem is inside the VM or in the networking layer.

Harden for Production

A freshly deployed OpenStack cluster works but is not production-ready without additional hardening. Enable TLS for all API endpoints by configuring Kolla-Ansible's TLS options in globals.yml, which places HAProxy in front of all services with SSL termination. Use certificates from your internal CA or Let's Encrypt for the public-facing endpoints.

For database high availability, Kolla-Ansible deploys MariaDB with Galera clustering automatically when you have multiple controller nodes. Verify that Galera replication is working by checking the cluster size variable on each database node. Similarly, RabbitMQ should be clustered across controller nodes with mirrored queues to prevent message loss if a node fails.

Replace the default LVM storage backend with Ceph for production block storage. Ceph provides replicated, distributed storage that survives disk and node failures without data loss. Kolla-Ansible includes Ceph deployment options, or you can connect to an existing Ceph cluster by configuring the RBD backend in Cinder's configuration. Ceph also integrates with Glance for image storage and Nova for instance ephemeral disks, creating a unified storage layer for the entire cloud.

Set up monitoring using Prometheus to collect metrics from all OpenStack services, with Grafana dashboards for visualization and alerting. Monitor API response times, RabbitMQ queue depths, database replication lag, Ceph cluster health, and compute node resource utilization. Configure alerts for conditions that indicate emerging problems before they become outages, such as growing queue depths, increasing API latency, or Ceph degraded placement groups.