From 8bd343d79602b2758f87a627a96b359e4313668c Mon Sep 17 00:00:00 2001 From: pareenaverma Date: Thu, 23 Apr 2026 17:30:16 -0400 Subject: [PATCH] Tech review of Openstack LP --- .../openstack-on-azure/_index.md | 3 +- .../openstack-on-azure/background.md | 47 ++--- .../devtstack-deployment.md | 188 ++++++++++-------- .../openstack-on-azure/instance.md | 40 +--- .../kolla-ansible-deployment.md | 132 +++++++++--- .../prepare-vm-for-kolla-ansible.md | 76 +++---- .../validation-vm-launch.md | 120 ++++++----- 7 files changed, 340 insertions(+), 266 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/_index.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/_index.md index 414708b7bb..341a7db0f1 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/_index.md @@ -1,11 +1,12 @@ --- title: Deploy OpenStack on Azure Cobalt 100 Arm64 Virtual Machine +description: Deploy OpenStack on Azure Cobalt 100 Arm64 virtual machines using DevStack for development and Kolla-Ansible for containerized production deployments. draft: true cascade: draft: true -minutes_to_complete: 60 +minutes_to_complete: 90 who_is_this_for: This learning path is designed for developers, DevOps engineers, and platform engineers who want to deploy and manage OpenStack on Arm-based cloud environments using Kolla-Ansible and DevStack. diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/background.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/background.md index 1fe682a295..a89eb0fb76 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/background.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/background.md @@ -47,35 +47,36 @@ A typical OpenStack deployment consists of: * **Networking (Neutron):** Handles virtual networking, bridges, and routing * **Storage Services:** Provide block and object storage -In this learning path, OpenStack is deployed using **Kolla-Ansible**, which runs services as containers for easier management. +## Two deployment approaches +This Learning Path covers two ways to deploy OpenStack on an Azure Cobalt 100 Arm64 VM. Each approach has different requirements and suits a different use case. -## Use cases +**DevStack** is a script-based installer designed for development and testing. It runs all OpenStack services directly on the host OS and is the fastest way to get a working OpenStack environment. It is not suitable for production. -OpenStack is widely used across industries: +**Kolla-Ansible** runs every OpenStack service as a Docker container and is the recommended approach for reproducible, production-grade deployments. It takes longer to set up but is easier to manage, upgrade, and extend. -* **Private Cloud Infrastructure:** Build internal cloud platforms -* **Dev/Test Environments:** Rapid provisioning of virtual machines -* **Edge Computing:** Lightweight deployments on Arm-based hardware -* **Telco Cloud:** Network function virtualization (NFV) -* **Research and HPC:** Scalable compute environments +| Feature | DevStack | Kolla-Ansible | +|---------|----------|---------------| +| Purpose | Development and testing | Production-grade deployment | +| Deployment method | Shell scripts on host OS | Docker containers via Ansible | +| Setup time | ~20 minutes | ~60 minutes | +| Arm64 images required | No | Yes (Debian-based) | +| Networking | Simplified (Neutron disabled) | Full Neutron with OVS | +| Horizon dashboard | Yes | Yes | -## Learn more about OpenStack +Each approach runs on its own dedicated VM. Do not run both on the same virtual machine — they use the same ports and will conflict. -To learn more about OpenStack, see: +## VM requirements for each deployment -- [OpenStack Official Website](https://www.openstack.org/) -- [OpenStack Documentation](https://docs.openstack.org/) -- [OpenStack GitHub Repository](https://github.com/openstack) -- [Kolla-Ansible Documentation](https://docs.openstack.org/kolla-ansible/latest/) +Because the two approaches have different infrastructure requirements, this Learning Path uses two separate Azure VMs. -## What you will learn +| | VM 1 — DevStack | VM 2 — Kolla-Ansible | +|-|-----------------|----------------------| +| vCPUs | 4 | 4 (8 recommended) | +| RAM | 8 GB | 16 GB recommended | +| OS disk | 80 GB | 100 GB | +| Data disk | None | 32 GB (for Cinder/Docker) | +| NICs | 1 (`eth0` with IP) | 2 (`eth0` management + `eth1` external) | +| OS | Ubuntu 24.04 | Ubuntu 24.04 | -In this learning path, you will: - -* Deploy OpenStack on an Azure Cobalt 100 Arm64 virtual machine -* Configure core OpenStack services (Keystone, Nova, Neutron, Glance, Cinder) -* Deploy containerized OpenStack using Kolla-Ansible -* Set up networking and storage for OpenStack -* Launch and manage virtual machine instances -* Access and manage resources using CLI and Horizon dashboard +You'll create VM 1 first, complete the DevStack deployment, then create and configure VM 2 before the Kolla-Ansible deployment. diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/devtstack-deployment.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/devtstack-deployment.md index c8d803641f..716bd5e75b 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/devtstack-deployment.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/devtstack-deployment.md @@ -1,6 +1,6 @@ --- title: Deploy OpenStack on Azure Arm using DevStack (Cobalt 100) -weight: 5 +weight: 4 ### FIXED, DO NOT MODIFY layout: learningpathall @@ -8,39 +8,19 @@ layout: learningpathall ## Deploy OpenStack on Arm using DevStack (Azure Cobalt 100) -{{% notice Note %}}Use the VM with a single network interface (DevStack setup). You do not need to add an extra NIC or data disk for these steps.{{% /notice %}} +{{% notice Note %}}Use the VM you created in the previous step: a single-NIC D4ps_v6 instance with at least 80 GB of disk. You do not need an extra NIC or data disk for DevStack.{{% /notice %}} -This guide walks you through deploying OpenStack using DevStack on an Arm-based Azure virtual machine (Azure Cobalt 100). +{{% notice Warning %}}DevStack and Kolla-Ansible must not run on the same VM at the same time. Use separate VMs for each approach. If you run both on the same host, port conflicts will cause deployment failures.{{% /notice %}} -DevStack is a lightweight OpenStack deployment tool designed for development and testing. -It installs core OpenStack services such as Nova, Keystone, Glance, and Horizon on a single node. +This guide walks you through deploying OpenStack using DevStack on an Arm-based Azure virtual machine running Azure Cobalt 100. DevStack is a script-based installer designed for development and testing. It runs all OpenStack services directly on the host OS and deploys Nova, Keystone, Glance, and Horizon on a single node. After completing this guide, your environment will: -* Run OpenStack services locally -* Provide access to the Horizon +* Run OpenStack services on your Azure Cobalt 100 VM +* Provide access to the Horizon dashboard * Support Arm64 (`aarch64`) architecture * Be accessible via browser and CLI -## Objective - -In this guide, you will: - -* Deploy OpenStack on Arm using DevStack -* Fix Arm-specific compatibility issues (etcd, libvirt) -* Access Horizon dashboard via public IP -* Validate services using OpenStack CLI - -## Environment - -| Component | Value | -| --------- | -------------------- | -| Platform | Azure Cobalt (Arm64) | -| OS | Ubuntu 24.04 | -| VM Size | D4ps_v6 | -| RAM | ≥ 8 GB | -| Disk | ≥ 80 GB | - ## Clean previous setup @@ -79,29 +59,22 @@ These tools are required for: ## Configure hostname +Setting a hostname avoids registration issues where OpenStack services identify themselves by hostname. Run: + ```console -sudo hostnamectl set-hostname devstack-Arm +sudo hostnamectl set-hostname devstack-arm exec bash ``` -Setting a consistent hostname ensures: - -* Proper service registration -* Correct identification in OpenStack services - ## Install etcd (Arm fix) -DevStack uses etcd internally, but on Ubuntu 24.04 Arm: - - * Built-in etcd service is unstable ❌ - -So we install a stable Arm-compatible version manually. +DevStack uses etcd internally for service coordination. The etcd package included in Ubuntu 24.04 is not built for Arm and is unstable in this environment. Install a known-stable Arm64 binary directly from the etcd GitHub releases instead. ```console cd /tmp -wget https://github.com/etcd-io/etcd/releases/download/v3.5.13/etcd-v3.5.13-linux-Arm64.tar.gz -tar -xvf etcd-v3.5.13-linux-Arm64.tar.gz -cd etcd-v3.5.13-linux-Arm64 +wget https://github.com/etcd-io/etcd/releases/download/v3.5.13/etcd-v3.5.13-linux-arm64.tar.gz +tar -xvf etcd-v3.5.13-linux-arm64.tar.gz +cd etcd-v3.5.13-linux-arm64 sudo cp etcd etcdctl /usr/local/bin/ ``` @@ -165,16 +138,26 @@ git clone https://opendev.org/openstack/devstack cd devstack ``` -This downloads the DevStack scripts required to install OpenStack. +This clones the DevStack repository, which contains the scripts that install and configure all OpenStack services. + +## Get private IP + +DevStack binds OpenStack services to the VM's private IP. Run the following command to find it: + +```console +hostname -I +``` + +If the output shows two addresses, use the first one. The second is typically an Azure secondary IP configuration. ## Configure DevStack +Create a `local.conf` file in the DevStack directory. This file controls which services are installed and how they are configured. + ```console vi local.conf ``` -### Arm-optimized configuration - ```ini [[local|localrc]] ADMIN_PASSWORD=admin @@ -205,22 +188,19 @@ ENABLE_HTTPD_MOD_WSGI_SERVICES=False LIBVIRT_TYPE=qemu disable_service tempest -``` -### Why these changes? +GIT_DEPTH=1 +``` -* **Disable Neutron** → avoids Arm networking issues -* **Disable etcd3** → uses our stable external etcd -* **LIBVIRT_TYPE=qemu** → avoids KVM issues on Arm -* **Enable Horizon** → provides web UI +Replace `` with the IP address from the previous step. -## Get private IP +### Key configuration choices -```console -hostname -I -``` - -Replace `` in `local.conf`. +* **Neutron disabled** — simplifies the deployment by removing advanced networking, which has compatibility issues on Arm Azure VMs +* **etcd3 disabled** — DevStack's built-in etcd setup does not work reliably on Arm; this delegates etcd to the version you installed manually +* **LIBVIRT_TYPE=qemu** — Azure Cobalt 100 VMs do not support nested KVM virtualization, so Nova uses QEMU software emulation instead +* **Horizon enabled** — enables the web dashboard +* **GIT_DEPTH=1** — performs shallow clones to reduce download size and avoid failures on slow or rate-limited connections ## Deploy OpenStack @@ -236,6 +216,27 @@ This script: **Deployment time: ~15–25 minutes** +When the deployment completes successfully, the output is similar to: + +```output +This is your host IP address: 10.3.0.5 +This is your host IPv6 address: ::1 +Horizon is now available at http://10.3.0.5/dashboard +Keystone is serving at http://10.3.0.5/identity/ +The default users are: admin and demo +The password: admin + +Services are running under systemd unit files. +For more information see: +https://docs.openstack.org/devstack/latest/systemd.html + +DevStack Version: 2026.2 +Change: 03ece8f88040be9b0b14dd1cfe93076ad2419a80 Merge "[neutron] Configure ovn-bgp service-plugin" 2026-04-10 12:15:11 +0000 +OS Version: Ubuntu 24.04 noble + +2026-04-23 16:30:00.225 | stack.sh completed in 464 seconds. +``` + ## Access Horizon dashboard Open in browser: @@ -250,7 +251,7 @@ Example: http://4.186.31.18/dashboard ``` -![OpenStack Horizon login page alt-txt#center](images/openstack-horizon-dashboard.png "OpenStack Horizon Login Screen") +![OpenStack Horizon login page showing username and password fields on the Azure Cobalt 100 VM#center](images/openstack-horizon-dashboard.png "OpenStack Horizon login screen") ## Login credentials @@ -274,6 +275,8 @@ Azure Portal → VM → Networking → Inbound Rules ## Verify via CLI +Activate the admin credentials, then list the registered services and compute services: + ```console source openrc admin admin @@ -281,22 +284,9 @@ openstack service list openstack compute service list ``` -## Expected output - -Services should include: - -```text -Keystone → OK -Nova → OK -Glance → OK -Placement → OK -Cinder → OK -``` - -Compute: +The output is similar to: -```text - import eventlet +```output +----------------------------------+-------------+----------------+ | ID | Name | Type | +----------------------------------+-------------+----------------+ @@ -308,28 +298,60 @@ Compute: | fd998beaffe64e2191795082470d03c0 | placement | placement | +----------------------------------+-------------+----------------+ - import eventlet +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ -| 46946541-a6c1-4b8c-92e3-5d037bb2d577 | nova-scheduler | devstack-Arm | internal | enabled | up | 2026-04-14T08:14:42.000000 | -| e1aa2f20-3f39-4d12-9702-4b144a739f56 | nova-conductor | devstack-Arm | internal | enabled | up | 2026-04-14T08:14:46.000000 | -| caeab24b-a938-420b-9ae0-e335ed8acfea | nova-conductor | devstack-Arm | internal | enabled | up | 2026-04-14T08:15:56.000000 | -| b612363d-b7ad-4c9e-93b8-afd20fb9b863 | nova-compute | devstack-Arm | nova | enabled | up | 2026-04-14T08:15:05.000000 | +| 46946541-a6c1-4b8c-92e3-5d037bb2d577 | nova-scheduler | devstack-arm | internal | enabled | up | 2026-04-14T08:14:42.000000 | +| e1aa2f20-3f39-4d12-9702-4b144a739f56 | nova-conductor | devstack-arm | internal | enabled | up | 2026-04-14T08:14:46.000000 | +| caeab24b-a938-420b-9ae0-e335ed8acfea | nova-conductor | devstack-arm | internal | enabled | up | 2026-04-14T08:15:56.000000 | +| b612363d-b7ad-4c9e-93b8-afd20fb9b863 | nova-compute | devstack-arm | nova | enabled | up | 2026-04-14T08:15:05.000000 | +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ - ``` +All services should show status `enabled` and state `up`. If you see `import eventlet` lines before the table, these are Python deprecation warnings from older OpenStack libraries and can be ignored. + ## What you've learned -You successfully deployed OpenStack using DevStack on an Arm-based Azure VM. +You deployed OpenStack using DevStack on an Azure Cobalt 100 Arm64 VM, working through several Arm-specific issues along the way: -You resolved Arm-specific issues, including: +* Replaced the Ubuntu etcd package with a stable Arm64 binary +* Disabled Neutron to avoid networking compatibility issues on Arm +* Configured Nova to use QEMU instead of KVM, because nested virtualization is not available on Azure VMs -* etcd compatibility -* networking limitations -* libvirt virtualization (QEMU) +You verified the deployment using the CLI and accessed the Horizon dashboard via browser. + +## Stop DevStack + +Before moving on to the Kolla-Ansible deployment, stop all DevStack services to free up the ports and resources they hold: + +```console +cd /home/azureuser/devstack && ./unstack.sh 2>&1 | tail -10 +``` + +The Kolla-Ansible deployment runs on a separate VM, so this step is optional if you're done with DevStack. Run it if you want to reuse this VM later or clean up resources. + +## Troubleshooting + +### Horizon shows "Invalid service catalog: network" + +If you see a `ServiceCatalogException: Invalid service catalog: network` error after logging in to Horizon, it means Horizon is trying to look up the Neutron network service in Keystone's service catalog. Because Neutron is disabled in this setup, the service doesn't exist. + +To fix this, append a Horizon configuration override and restart Apache: + +```bash +sudo tee -a /opt/stack/horizon/openstack_dashboard/local/local_settings.py << 'EOF' + +OPENSTACK_NEUTRON_NETWORK = { + 'enable_router': False, + 'enable_quotas': False, + 'enable_distributed_router': False, + 'enable_ha_router': False, + 'enable_fip_topology_check': False, +} +EOF +sudo systemctl restart apache2 +``` -You validated the deployment using CLI and accessed the Horizon UI. +Reload the dashboard in your browser. The error should no longer appear. diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/instance.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/instance.md index 103c6b50bc..6fc27f0b70 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/instance.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/instance.md @@ -1,5 +1,5 @@ --- -title: Create an Azure Cobalt 100 Arm64 virtual machine +title: Create an Azure Cobalt 100 Arm64 virtual machine for DevStack weight: 3 ### FIXED, DO NOT MODIFY @@ -31,7 +31,7 @@ Creating a virtual machine based on Azure Cobalt 100 is no different to creating - In the **Size** field, select **See all sizes** and select the D-Series v6 family of virtual machines. - Select **D4ps_v6** from the list as shown in the diagram below: -![Azure Portal VM size selection showing the D-Series v6 (Dpsv6) family highlighted with D4ps_v6 option selected for Arm64 architecture alt-txt#center](images/instance.png "Select D4ps_v6 from the D-Series v6 family") +![Azure Portal VM size selection showing the D-Series v6 (Dpsv6) family highlighted with the D4ps_v6 Arm64 instance selected#center](images/instance.png "Select D4ps_v6 from the D-Series v6 family") - For **Authentication type**, select **SSH public key**. @@ -49,48 +49,24 @@ RSA offers better security with keys longer than 3072 bits. - Give your SSH key a key pair name. - In the **Inbound port rules**, select **HTTP (80)** and **SSH (22)** as the inbound ports, as shown below: -![Azure Portal inbound port rules configuration showing HTTP (80) and SSH (22) selected as allowed incoming traffic alt-txt#center](images/instance1.png "Configure inbound port rules for HTTP and SSH access") +![Azure Portal inbound port rules configuration showing HTTP (80) and SSH (22) selected as allowed incoming traffic#center](images/instance1.png "Configure inbound port rules for HTTP and SSH access") - Now select the **Review + Create** tab and review the configuration for your virtual machine. It should look like the following: -![Azure Portal Review + Create tab showing VM configuration summary with Ubuntu Pro 24.04 LTS image, D4ps_v6 size, and networking settings configured alt-txt#center](images/ubuntu-pro.png "Review VM configuration before creation") +![Azure Portal Review + Create tab showing VM configuration summary with Ubuntu Pro 24.04 LTS image, D4ps_v6 size, and networking settings configured#center](images/ubuntu-pro.png "Review VM configuration before creation") - When you are happy with your selection, select the **Create** button and then **Download Private key and Create Resource** button. -![Azure Portal showing the Create button and Download Private key and Create Resource button to finalize VM creation alt-txt#center](images/instance4.png "Download SSH key and create the virtual machine") +![Azure Portal showing the Create button and Download Private key and Create Resource button to finalize VM creation#center](images/instance4.png "Download SSH key and create the virtual machine") Your virtual machine should be ready and running in a few minutes. You can SSH into the virtual machine using the private key, along with the public IP details. -![Azure Portal showing successful VM deployment with green checkmark, VM name, resource group, and public IP address displayed in the confirmation notification alt-txt#center](images/final-vm.png "Successful VM deployment confirmation") +![Azure Portal showing successful VM deployment with green checkmark, VM name, resource group, and public IP address displayed in the confirmation notification#center](images/final-vm.png "Successful VM deployment confirmation") {{% notice Note %}}To learn more about Arm-based virtual machine in Azure, see “Getting Started with Microsoft Azure” in [Get started with Arm-based cloud instances](/learning-paths/servers-and-cloud-computing/csp/azure).{{% /notice %}} ## What you've accomplished and what's next -You've successfully: +You've created an Azure Cobalt 100 Arm-based virtual machine using Ubuntu Pro 24.04 LTS on a D4ps_v6 instance. This VM is your **DevStack deployment target** — a single-NIC instance with at least 80 GB of disk. -* Created an Azure Cobalt 100 Arm-based virtual machine using the D-Series v6 (Dpsv6) family -* Selected Ubuntu Pro 24.04 LTS as the operating system -* Configured SSH authentication for secure access - -## Additional setup for this learning path - -This learning path requires **two virtual machines** with the same base configuration: - -* VM 1 → Used for DevStack deployment (single NIC setup) -* VM 2 → Used for Kolla-Ansible deployment (advanced setup) - -{{% notice Note %}}Two separate VMs are recommended because running DevStack and Kolla-Ansible on the same machine can lead to service and port conflicts during deployment.{{% /notice %}} - -Both virtual machines should be created using the steps described above. - - -## What's next - -In the next section, you will prepare the second virtual machine for Kolla-Ansible by: - -* Adding an additional network interface (NIC) -* Attaching a data disk -* Configuring the system for OpenStack deployment - -This setup enables proper networking and storage configuration required for containerized OpenStack using Kolla-Ansible. +In the next section, you'll deploy OpenStack on this VM using DevStack. After that, you'll create a second VM with additional networking and storage for the Kolla-Ansible deployment. diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/kolla-ansible-deployment.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/kolla-ansible-deployment.md index e247245817..28bab6faa0 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/kolla-ansible-deployment.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/kolla-ansible-deployment.md @@ -10,6 +10,8 @@ layout: learningpathall {{% notice Note %}}Use the virtual machine prepared for Kolla-Ansible deployment (with dual NICs and a data disk). This setup is required for proper networking and storage configuration.{{% /notice %}} +{{% notice Warning %}}**DevStack and Kolla-Ansible are separate deployment approaches and must not run on the same VM at the same time.** If you have previously run a DevStack deployment on this VM, stop it completely before proceeding. Kolla-Ansible deploys OpenStack services as Docker containers on the same ports that DevStack uses. Running both on the same host will cause port conflicts and service startup failures. Use a separate VM for each approach, or unstack DevStack fully before attempting this deployment.{{% /notice %}} + This guide walks you through deploying OpenStack using Kolla-Ansible on an Azure Ubuntu 24.04 Arm64 virtual machine. Kolla-Ansible deploys OpenStack services as Docker containers, making the deployment modular, reproducible, and easier to manage. @@ -56,7 +58,7 @@ meson ninja-build curl These packages are required for Python builds and OpenStack dependencies. -## install Docker +## Install Docker Docker is used to run all OpenStack services as containers. @@ -139,6 +141,8 @@ neutron_external_interface: "eth1" kolla_internal_vip_address: "127.0.0.1" enable_keepalived: "no" + +nova_compute_virt_type: "qemu" ``` ### Why this configuration? @@ -146,7 +150,8 @@ enable_keepalived: "no" - **Debian base** → Arm images are available - **aarch64 suffix** → ensures correct image selection - **VIP = VM IP** → avoids Azure networking issues -- **HA disabled**→ required for single-node deployments +- **HA disabled** → required for single-node deployments +- **nova_compute_virt_type=qemu** → overrides the default KVM setting globally; ensures Nova uses QEMU on Arm VMs where KVM is unavailable ## Configure Nova (Arm fix) @@ -164,7 +169,7 @@ EOF ### Why this is required -Arm-based Azure VMs do not support KVM virtualization. Using QEMU ensures that instances can be launched successfully. +Arm-based Azure VMs do not support KVM virtualization. Setting `virt_type = qemu` and `cpu_mode = none` ensures Nova uses QEMU emulation, which works on Arm VMs where KVM is unavailable. Kolla deploys libvirt inside its own `nova_libvirt` container and manages the connection URI automatically. ## Generate passwords @@ -176,7 +181,17 @@ This creates all required passwords for OpenStack services. ## Deploy OpenStack -Run the following commands in order: +The deployment runs in five stages. Each stage must complete successfully before the next one starts. + +| Stage | Command | What it does | +|-------|---------|-------------| +| Bootstrap | `bootstrap-servers` | Configures the host: Docker users, directories, and system settings | +| Prechecks | `prechecks` | Validates that the environment meets all requirements | +| Pull | `pull` | Downloads OpenStack container images from the registry | +| Deploy | `deploy` | Starts all OpenStack service containers | +| Post-deploy | `post-deploy` | Generates admin credentials and writes `admin-openrc.sh` | + +Run each command and wait for it to complete before proceeding: ```console kolla-ansible bootstrap-servers -i all-in-one @@ -214,9 +229,10 @@ skipping: no hosts matched PLAY RECAP *************************************************************************************************************************** localhost : ok=33 changed=14 unreachable=0 failed=0 skipped=52 rescued=0 ignored=0 ``` + ```console -kolla-ansible deploy -i all-in-one deploy -```` +kolla-ansible deploy -i all-in-one +``` The output is similar to: @@ -228,39 +244,33 @@ PLAY RECAP ********************************************************************* localhost : ok=368 changed=34 unreachable=0 failed=0 skipped=267 rescued=0 ignored=0 ``` -#### What happens during deployment? - -- **Bootstrap** → prepares system (Docker, users, configs) -- **Prechecks** → validates environment -- **Pull** → downloads OpenStack container images -- **Deploy** → starts all services -- **Post-deploy** → generates access credentials +The deploy step starts all OpenStack service containers. It takes the longest of the five stages — allow 20 to 30 minutes. ```console -kolla-ansible -i all-in-one post-deploy +kolla-ansible post-deploy -i all-in-one ``` -## Load environment +## Install the OpenStack client and load credentials + +The OpenStack CLI is not included in Kolla-Ansible. Install it inside the virtual environment, then load the admin credentials that `post-deploy` generated: ```console +source ~/kolla-venv/bin/activate +pip install python-openstackclient source /etc/kolla/admin-openrc.sh ``` -This enables OpenStack CLI commands. - ## Verify services +Confirm that all Nova compute services and Neutron network agents are running: + ```console openstack compute service list -openstack network agent list ``` -All services should be UP. - The output is similar to: ```output -openstack network agent list +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ @@ -268,6 +278,15 @@ openstack network agent list | 2054f4ad-2492-46e4-990a-4fdf7d40e20f | nova-conductor | ansible-d8ps | internal | enabled | up | 2026-04-14T07:38:11.000000 | | b0d28456-483b-4a9c-bcaf-5932364e32b6 | nova-compute | ansible-d8ps | nova | enabled | up | 2026-04-14T07:38:16.000000 | +--------------------------------------+----------------+--------------+----------+---------+-------+----------------------------+ +``` + +```console +openstack network agent list +``` + +The output is similar to: + +```output +------------------------+--------------------+--------------+-------------------+-------+-------+--------------------------+ | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | +------------------------+--------------------+--------------+-------------------+-------+-------+--------------------------+ @@ -282,16 +301,71 @@ openstack network agent list +------------------------+--------------------+--------------+-------------------+-------+-------+--------------------------+ ``` +All services should show `enabled` and state `up`. If any service shows `down`, check the container logs with `docker logs `. + ## What you've learned -You successfully deployed OpenStack using Kolla-Ansible on an Arm-based Azure VM. +You deployed OpenStack using Kolla-Ansible on an Azure Cobalt 100 Arm64 VM. The deployment ran all OpenStack services as Docker containers, including Nova, Neutron, Keystone, Glance, and Horizon. + +Along the way, you worked through several challenges specific to Arm and Azure: + +- Applied the Debian-based Arm64 image suffix so Kolla pulls the correct container images +- Configured Nova to use QEMU instead of KVM, because Azure Cobalt 100 VMs don't support nested virtualization +- Disabled keepalived and used the VM's own IP as the internal VIP, which is required for single-node Azure deployments +- Allowed Kolla to manage libvirt internally via its `nova_libvirt` container, rather than running host libvirt + +Your environment is now ready to launch and manage virtual machines. -You also resolved key challenges, including: +## Troubleshooting -- Docker permission issues -- Arm virtualization limitations (QEMU) -- Image compatibility (aarch64) -- Azure networking constraints (VIP handling) -- Single-node deployment limitations (HA disabled) +### Docker fails to restart during bootstrap -You now have a fully functional OpenStack environment capable of launching and managing virtual machines. +If `kolla-ansible bootstrap-servers` fails with the following error: + +```output +RUNNING HANDLER [openstack.kolla.docker : Restart docker] +fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to start service docker: Job for docker.service failed because the control process exited with error code.\nSee \"systemctl status docker.service\" and \"journalctl -xeu docker.service\" for details.\n"} +``` + +Kolla-Ansible modifies Docker's systemd unit files during bootstrap. If Docker is already running, the service can enter a failed state that blocks restarts. + +Run these three commands to recover: + +```console +sudo systemctl daemon-reload +sudo systemctl reset-failed docker.socket docker.service +sudo systemctl restart docker +``` + +- `daemon-reload` picks up the updated unit files written by Kolla-Ansible +- `reset-failed` clears the failed state that was blocking the restart +- `restart docker` starts Docker cleanly + +After Docker is running, re-run the bootstrap step: + +```console +kolla-ansible bootstrap-servers -i all-in-one +``` + +### Prechecks fail with "host libvirt is running" + +Kolla-Ansible manages libvirt inside its own `nova_libvirt` container. If host `libvirtd` is running, prechecks will fail with: + +```output +TASK [nova-cell : Checking that host libvirt is not running] +fatal: [localhost]: FAILED! +``` + +Stop and disable the host libvirt service before running prechecks: + +```console +sudo systemctl stop libvirtd 2>/dev/null || true +sudo systemctl disable libvirtd 2>/dev/null || true +sudo rm -f /var/run/libvirt/libvirt-sock +``` + +Then re-run prechecks: + +```console +kolla-ansible prechecks -i all-in-one +``` diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/prepare-vm-for-kolla-ansible.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/prepare-vm-for-kolla-ansible.md index 7c4c79ed72..8e1a92e827 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/prepare-vm-for-kolla-ansible.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/prepare-vm-for-kolla-ansible.md @@ -1,44 +1,40 @@ --- title: Prepare Azure Arm64 VM for Kolla-Ansible (Network and Storage Setup) -weight: 4 +weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Prepare VM for Kolla-Ansible Deployment +## Prepare a second VM for Kolla-Ansible -Before deploying OpenStack using Kolla-Ansible, the Azure virtual machine must be prepared with proper networking and storage. +You've completed the DevStack deployment on VM 1. The Kolla-Ansible deployment runs on a **separate** Azure VM with a more complex configuration: it needs two network interfaces and a dedicated data disk. -In this section, you will: +Create a new VM using the same base process as VM 1 (Ubuntu Pro 24.04 LTS, D4ps_v6, SSH key auth), then follow the steps below to add the required networking and storage. -* Add a second network interface (NIC) -* Attach a data disk -* Prepare the VM for OpenStack networking and storage +| | VM 1 — DevStack (done) | VM 2 — Kolla-Ansible (this section) | +|-|------------------------|--------------------------------------| +| NICs | 1 (`eth0`) | 2 (`eth0` + `eth1`) | +| Data disk | None | 32 GB | +| RAM | 8 GB | 16 GB recommended | +| Purpose | Dev/test deployment | Containerized production deployment | -## Why this setup is required +Once the new VM is running, complete the following steps before starting the Kolla-Ansible deployment. -OpenStack requires multiple network layers: +# Step 1: Add a second NIC in Azure -* **Management network (`eth0`)** → internal communication -* **External network (`eth1`)** → VM traffic (provider network) -* **Dedicated storage disk** → for Cinder and container storage +Kolla-Ansible requires two network interfaces: -Without this setup, VM networking and storage services will fail. +* `eth0` — management network, carries API traffic between OpenStack services +* `eth1` — external/provider network, carries traffic to and from virtual machine instances -# Step 1: Add a second NIC in Azure +Azure does not allow NIC attachment to a running VM. Stop the VM first. ## Stop the VM -Go to: - -* Azure Portal → Virtual Machines -* Select your VM -* Click **Stop** +Navigate to **Virtual Machines**, select your VM, and click **Stop**. -![Azure VM stop button highlighted alt-txt#center](images/kolla-ansible-nic1.png "Stopping the VM before attaching NIC") - -Stopping the VM is required because Azure does not allow NIC attachment while the VM is running. +![Azure Portal showing the VM Stop button highlighted in the top action bar, used to shut down the VM before attaching a NIC#center](images/kolla-ansible-nic1.png "Stop the VM before attaching a network interface") ## Attach a new NIC @@ -46,16 +42,17 @@ Stopping the VM is required because Azure does not allow NIC attachment while th * Click **Attach network interface** * Select **Create new NIC** -![Create NIC configuration screen alt-txt#center](images/kolla-ansible-nic2.png "Creating new NIC for OpenStack external network") +![Azure Portal Create NIC configuration screen showing subnet selection and name field for the new network interface#center](images/kolla-ansible-nic2.png "Create a new NIC for the OpenStack external network") ## Configure NIC * Keep the NIC in the same Virtual Network -* Select the same subnet +* Select the same subnet +* Enter a Name * Do **NOT** assign a public IP * Click **Create** -![Attach network interface option alt-txt#center](images/kolla-ansible-nic3.png "Attach network interface in Azure") +![Azure Portal Networking settings showing the Attach network interface option selected in the Network settings panel#center](images/kolla-ansible-nic3.png "Attach network interface in Azure Networking settings") ## Start the VM @@ -78,31 +75,22 @@ Stopping the VM is required because Azure does not allow NIC attachment while th * Type: **Standard SSD** * Click **Apply** -![Attach data disk in Azure alt-txt#center](images/kolla-ansible-data-disk.png "Adding data disk for OpenStack storage") +![Azure Portal Disks settings showing the newly attached 32 GB Standard SSD listed under data disks#center](images/kolla-ansible-data-disk.png "32 GB data disk attached for OpenStack storage") -## Why this disk is important +## Why this disk is required -This disk will be used for: +Kolla-Ansible uses a dedicated disk for: -* Cinder (block storage) -* Docker volumes -* OpenStack service data +* **Cinder** — provides block storage volumes to OpenStack instances +* **Docker volumes** — stores container data for all OpenStack services -Using a separate disk ensures better performance and avoids filling the OS disk. +Using a separate disk keeps OpenStack data off the OS disk and avoids filling it during deployment. ## What you've accomplished -You successfully prepared the Azure Arm64 virtual machine for Kolla-Ansible by: - -* Adding and configuring a second network interface -* Attaching a dedicated storage disk -* Preparing networking for the OpenStack provider network -* Ensuring the system is ready for containerized OpenStack deployment - -## What's next +You've prepared a second Azure Arm64 VM for Kolla-Ansible with: -In the next section, you will: +* A second NIC (`eth1`) for OpenStack's provider network +* A dedicated 32 GB data disk for Cinder and Docker volumes -* Install Kolla-Ansible -* Deploy OpenStack services -* Validate the deployment +In the next section, you'll install Kolla-Ansible and deploy OpenStack as containers on this VM. diff --git a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch.md b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch.md index 9ae8d2ab5e..525d97687c 100644 --- a/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch.md +++ b/content/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch.md @@ -1,40 +1,22 @@ --- -title: Validate OpenStack Deployment and Launch VM on Azure Cobalt 100 vm +title: Validate OpenStack deployment and launch a VM on Azure Cobalt 100 weight: 7 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Validate OpenStack Deployment and Launch a Virtual Machine +## Validate OpenStack deployment and launch a virtual machine -After deploying OpenStack using Kolla-Ansible, it is important to verify that all services are functioning correctly and that the environment can successfully launch virtual machines. +This section validates the Kolla-Ansible deployment by checking service health, uploading a test image, creating network resources, and launching a virtual machine instance. -In this guide, you will: - -* Validate OpenStack services -* Fix common Arm + Azure networking issues -* Upload an Arm-compatible image -* Create network and compute resources -* Launch and verify a virtual machine - - -## Install OpenStack CLI (if not installed) - -```console -pip install python-openstackclient -``` - -This tool allows you to interact with OpenStack services via the command line. - -## Load admin credentials +If you closed your session since the Kolla-Ansible deployment, reactivate the virtual environment and reload the admin credentials: ```console +source ~/kolla-venv/bin/activate source /etc/kolla/admin-openrc.sh ``` -This sets environment variables required to authenticate with OpenStack. - ## Verify services ```console @@ -51,17 +33,11 @@ All services should show: If any service is down, the deployment is incomplete or misconfigured. -## Open vSwitch bridges - -In Arm + Azure environments, OVS bridges may not come up automatically. - -This causes: +## Bring up Open vSwitch bridges -* VM stuck in `ERROR` -* No networking -* No IP assignment +Kolla-Ansible creates Open vSwitch (OVS) bridges for internal networking. On Arm Azure VMs, these bridges may not come up automatically after deployment, which causes instances to get stuck in `ERROR` state with no IP assignment. -Run the following commands: +Bring the bridges up manually: ```console sudo ip link set br-int up @@ -69,35 +45,77 @@ sudo ip link set br-ex up sudo ip link set br-tun up ``` -Verify OVS configuration: +Verify OVS configuration. Kolla-Ansible runs OVS inside the `openvswitch_vswitchd` container, so use `docker exec` to query it: ```console -sudo ovs-vsctl show +docker exec openvswitch_vswitchd ovs-vsctl show ``` -**Expected output:** - -You should see: +The output is similar to: -- br-int → integration bridge -- br-ex → external bridge -- br-tun → tunnel bridge +```output +65e7f7e-0018-4c05-84d6-83db06b812ee + Manager "ptcp:6640:127.0.0.1" + is_connected: true + Bridge br-ex + Controller "tcp:127.0.0.1:6633" + is_connected: true + fail_mode: secure + datapath_type: system + Port eth1 + Interface eth1 + Port br-ex + Interface br-ex + type: internal + Port phy-br-ex + Interface phy-br-ex + type: patch + options: {peer=int-br-ex} + Bridge br-int + Controller "tcp:127.0.0.1:6633" + is_connected: true + fail_mode: secure + datapath_type: system + Port patch-tun + Interface patch-tun + type: patch + options: {peer=patch-int} + Port int-br-ex + Interface int-br-ex + type: patch + options: {peer=phy-br-ex} + Port br-int + Interface br-int + type: internal + Bridge br-tun + Controller "tcp:127.0.0.1:6633" + is_connected: true + fail_mode: secure + datapath_type: system + Port br-tun + Interface br-tun + type: internal + Port patch-int + Interface patch-int + type: patch + options: {peer=patch-tun} +``` -All bridges must exist and be active. +All three bridges must show `is_connected: true`. If a bridge is missing or shows `is_connected: false`, re-run the `ip link set` commands above and check that the `neutron-openvswitch-agent` container is running with `docker ps | grep openvswitch`. ## Upload image Download a Debian Arm64 cloud image: ```console -wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-Arm64.qcow2 +wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-arm64.qcow2 ``` Upload it to OpenStack: ```console openstack image create "test-image" \ - --file debian-12-genericcloud-Arm64.qcow2 \ + --file debian-12-genericcloud-arm64.qcow2 \ --disk-format qcow2 \ --container-format bare \ --public @@ -174,20 +192,14 @@ Both should show your created resources. ## Create flavor +A flavor defines the compute resources — vCPUs, RAM, and disk — allocated to a virtual machine instance. OpenStack does not create any default flavors during deployment, so you need to create at least one before you can launch a VM. + +The `m1.tiny` flavor used here is a minimal definition suitable for testing: 1 vCPU, 512 MB RAM, and a 5 GB root disk. This is enough to boot a Debian cloud image and confirm the environment is working. + ```console openstack flavor create m1.tiny --ram 512 --disk 5 --vcpus 1 ``` -### Why is flavor required - -A flavor defines: - -- CPU -- RAM -- Disk - -for the virtual machine. - ## Verify flavor ```console @@ -258,7 +270,7 @@ Login: The following image shows a successfully launched instance in the OpenStack Horizon UI. -![OpenStack Horizon dashboard showing running instance test-vm alt-txt#center](images/openstack-ui.png "OpenStack Horizon Instances view with ACTIVE VM") +![OpenStack Horizon Instances page showing test-vm in ACTIVE state with an assigned IP address from the test-net network#center](images/openstack-ui.png "OpenStack Horizon Instances view with running VM") ## What you've learned