# [Validate OpenStack deployment and launch a virtual machine on Azure Cobalt 100](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch/) ## In this learning path - [Introduction](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/) - [Understand Azure Cobalt 100 and OpenStack](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/background/) - [Create an Azure Cobalt 100 Arm64 virtual machine for DevStack](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/instance/) - [Deploy OpenStack on an Azure Cobalt 100 Arm64 virtual machine using DevStack](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/devtstack-deployment/) - [Prepare Azure Arm64 virtual machine for Kolla-Ansible](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/prepare-vm-for-kolla-ansible/) - [Deploy OpenStack using Kolla-Ansible on an Azure Ubuntu Arm64 virtual machine](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/kolla-ansible-deployment/) - [Validate OpenStack deployment and launch a virtual machine on Azure Cobalt 100](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/validation-vm-launch/) - [Next Steps](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/_next-steps/) In this section, you’ll validate the Kolla-Ansible deployment by checking service health, uploading a test image, creating network resources, and launching a virtual machine instance. If you closed your session since the Kolla-Ansible deployment, reactivate the virtual environment and reload the admin credentials: ``` source ~/kolla-venv/bin/activate source /etc/kolla/admin-openrc.sh ``` ## Verify services Verify the OpenStack services: ``` openstack compute service list openstack network agent list ``` All services should show **Status** as **enabled** and **State** as **up**. If any service is down, the deployment is incomplete or misconfigured. ## Bring up Open vSwitch bridges 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. Bring the bridges up manually: ``` sudo ip link set br-int up sudo ip link set br-ex up sudo ip link set br-tun up ``` Verify OVS configuration. Kolla-Ansible runs OVS inside the `openvswitch_vswitchd` container, so use `docker exec` to query it: ``` docker exec openvswitch_vswitchd ovs-vsctl show ``` The output is similar to: ``` __output__ 65e7f7e-0018-4c05-84d6-83db06b812ee __output__ Manager "ptcp:6640:127.0.0.1" __output__ is_connected: true __output__ Bridge br-ex __output__ Controller "tcp:127.0.0.1:6633" __output__ is_connected: true __output__ fail_mode: secure __output__ datapath_type: system __output__ Port eth1 __output__ Interface eth1 __output__ Port br-ex __output__ Interface br-ex __output__ type: internal __output__ Port phy-br-ex __output__ Interface phy-br-ex __output__ type: patch __output__ options: {peer=int-br-ex} __output__ Bridge br-int __output__ Controller "tcp:127.0.0.1:6633" __output__ is_connected: true __output__ fail_mode: secure __output__ datapath_type: system __output__ Port patch-tun __output__ Interface patch-tun __output__ type: patch __output__ options: {peer=patch-int} __output__ Port int-br-ex __output__ Interface int-br-ex __output__ type: patch __output__ options: {peer=phy-br-ex} __output__ Port br-int __output__ Interface br-int __output__ type: internal __output__ Bridge br-tun __output__ Controller "tcp:127.0.0.1:6633" __output__ is_connected: true __output__ fail_mode: secure __output__ datapath_type: system __output__ Port br-tun __output__ Interface br-tun __output__ type: internal __output__ Port patch-int __output__ Interface patch-int __output__ type: patch __output__ options: {peer=patch-tun} ``` 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 and check that the `neutron-openvswitch-agent` container is running with `docker ps | grep openvswitch`. ## Upload image Download a Debian Arm64 cloud image: ``` wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-arm64.qcow2 ``` Upload it to OpenStack: ``` openstack image create "test-image" \ --file debian-12-genericcloud-arm64.qcow2 \ --disk-format qcow2 \ --container-format bare \ --public ``` Verify the image upload: ``` openstack image list ``` The output is similar to: ``` __output__ +--------------------------------------+------------+--------+ __output__ | ID | Name | Status | __output__ +--------------------------------------+------------+--------+ __output__ | 4537107d-4c52-4537-a3d2-bd5c5a13de5b | test-image | active | __output__ +--------------------------------------+------------+--------+ ``` The image must be in an active state before launching VMs. ## Create network OpenStack networking (Neutron) requires a logical network and an IP range for instances. Create a network: ``` openstack network create test-net openstack subnet create test-subnet \ --network test-net \ --subnet-range 192.168.0.0/24 ``` Verify the network: ``` openstack network list ``` The output is similar to: ``` __output__ +--------------------------------------+----------+--------------------------------------+ __output__ | ID | Name | Subnets | __output__ +--------------------------------------+----------+--------------------------------------+ __output__ | 1d8b3cc8-a2d3-476c-86d7-4b9533dbefb2 | test-net | a31916fa-783b-4b25-8acb-8694007b9198 | __output__ +--------------------------------------+----------+--------------------------------------+ ``` Verify the subnet: ``` openstack subnet list ``` The output is similar to: ``` __output__ +--------------------------------------+-------------+--------------------------------------+----------------+ __output__ | ID | Name | Network | Subnet | __output__ +--------------------------------------+-------------+--------------------------------------+----------------+ __output__ | a31916fa-783b-4b25-8acb-8694007b9198 | test-subnet | 1d8b3cc8-a2d3-476c-86d7-4b9533dbefb2 | 192.168.0.0/24 | __output__ +--------------------------------------+-------------+--------------------------------------+----------------+ ``` Both outputs 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: ``` openstack flavor create m1.tiny --ram 512 --disk 5 --vcpus 1 ``` 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. Verify the flavor: ``` openstack flavor list ``` The output is similar to: ``` __output__ +--------------------------------------+---------+-----+------+-----------+-------+-----------+ __output__ | ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public | __output__ +--------------------------------------+---------+-----+------+-----------+-------+-----------+ __output__ | 20ea160b-bff7-4c2a-be1e-588a44dc699a | m1.tiny | 512 | 5 | 0 | 1 | True | __output__ +--------------------------------------+---------+-----+------+-----------+-------+-----------+ ``` ## Launch a virtual machine To launch a VM, run: ``` openstack server create \ --flavor m1.tiny \ --image test-image \ --network test-net \ test-vm ``` Verify VM status: ``` watch -n 2 openstack server list ``` The output is similar to: ``` __output__ +--------------------------------------+---------+--------+------------------------+------------+---------+ __output__ | ID | Name | Status | Networks | Image | Flavor | __output__ +--------------------------------------+---------+--------+------------------------+------------+---------+ __output__ | 4f42729c-0635-40e2-9432-ac056e40f781 | test-vm | ACTIVE | test-net=192.168.0.150 | test-image | m1.tiny | __output__ +--------------------------------------+---------+--------+------------------------+------------+---------+ ``` If the VM stays in ERROR, check the following: - OVS bridges - compute service status - image compatibility ## Access Horizon dashboard Open a browser and navigate to the public IP address of the VM: ``` http:// ``` Retrieve the admin password: ``` cat /etc/kolla/passwords.yml | grep keystone_admin_password ``` Log in with the following credentials: | Field | Value | |-----------|-------------------------------------| | Username | admin | | Password | (output of password retrieval command) | | Domain | Default | The following image shows a successfully launched instance in the OpenStack Horizon UI. ![OpenStack Horizon Instances view with running VM](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openstack-on-azure/images/openstack-ui.png) ## What you’ve accomplished You validated your Kolla-Ansible OpenStack deployment end-to-end. You checked service health, configured OVS bridges for Arm on Azure, uploaded an Arm-compatible Debian image, created network and compute resources, and launched a running virtual machine. Your OpenStack environment is now fully functional and ready for use.