Launching an instance is the moment OpenStack stops feeling like an abstract collection of services and starts feeling like a cloud. Nova, the compute service, takes a handful of inputs — an image, a flavor, a network, a keypair, and a security group — and schedules a virtual machine onto a hypervisor for you. This is the self-service experience that public clouds made famous, running on your own hardware.

In this tutorial you will gather those building blocks and boot your first instance entirely from the OpenStack CLI, then connect to it over SSH. It assumes you have a working cloud and a project-scoped user, as set up in create an OpenStack project and user.

Prerequisites

• A running OpenStack 2025.2 cloud with the openstack client installed.
• Project-scoped credentials sourced into your shell (your openrc).
• At least one image in Glance and an external/provider network reachable from your project. Building the latter is covered in Neutron networks, routers and floating IPs.

Step 1: Survey what is available

Before booting anything, list the four ingredients Nova needs. This also confirms your credentials and quotas are working:

openstack image list
openstack flavor list
openstack network list
openstack security group list

A flavor defines the virtual hardware — vCPUs, RAM, and root disk. An image is the operating system template. If your cloud is fresh, you may only have the Cirros test image; that is fine for a first boot.

Step 2: Upload an image (if needed)

To run something more useful than Cirros, download a cloud image and upload it to Glance. Cloud images are pre-configured to accept SSH keys and run cloud-init on first boot.

wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
openstack image create 'ubuntu-24.04' \
  --file noble-server-cloudimg-amd64.img \
  --disk-format qcow2 --container-format bare \
  --property hw_disk_bus=virtio --public

Step 3: Create a keypair

Cloud images do not have passwords; you log in with an SSH key that cloud-init injects at boot. Create a keypair and keep the private half safe. You can let OpenStack generate one, or upload your existing public key:

openstack keypair create mykey > ~/.ssh/mykey.pem
chmod 600 ~/.ssh/mykey.pem
Or upload an existing public key:
openstack keypair create --public-key ~/.ssh/id_ed25519.pub mykey

Step 4: Allow SSH with a security group

By default the security group blocks all inbound traffic. Add a rule that permits SSH so you can reach the instance. Security groups are covered in depth in OpenStack security groups and keypairs; for now, one rule is enough:

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

Step 5: Boot the instance

Now combine everything into a single server create command. Pick a flavor and the network you want to attach to, reference your keypair and security group, and give the instance a name:

openstack server create 

--flavor m1.small 

--image ubuntu-24.04 

--network acme-net 

--security-group default 

--key-name mykey 

--wait 

web-01

The --wait flag holds the command until Nova reports the instance ACTIVE or ERROR. Watch the status field; a healthy boot looks like this:

openstack server show web-01 -c status -c addresses

+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| addresses | acme-net=10.0.0.42               |
| status    | ACTIVE                           |
+-----------+----------------------------------+

Step 6: Assign a floating IP and connect

The instance has a private address on the tenant network. To reach it from outside, allocate a floating IP from the external network and associate it:

openstack floating ip create ext-net
openstack server add floating ip web-01 203.0.113.50
ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.50

The default login user depends on the image — ubuntu for Ubuntu cloud images, cirros for Cirros, centos or cloud-user for others.

Verification

Confirm the instance is healthy from both the control plane and inside the VM. The console log is invaluable: it shows the boot sequence and whether cloud-init pulled in your key:

openstack console log show web-01 | tail -n 20
openstack server list

inside the VM:
uptime && ip a

Common errors and troubleshooting

Status is ERROR right after creation

The scheduler could not place the instance. Read the fault directly with openstack server show web-01 -c fault. The usual causes are no host with enough RAM/CPU (No valid host was found) or an exhausted quota — check with openstack quota show.

Instance is ACTIVE but SSH times out

Almost always a networking or security-group issue. Confirm the SSH rule exists, that the floating IP is associated, and that a router connects your tenant network to the external one. The console log will tell you if the VM itself booted correctly.

Permission denied (publickey)

The key was not injected, usually because you booted a non-cloud image or cloud-init failed. Use a proper cloud image, confirm --key-name was set, and check the console log for cloud-init errors.

Cleaning up

Delete the instance and release the floating IP when you are done so you do not waste quota:

openstack server delete web-01
openstack floating ip delete 203.0.113.50

Conclusion

You have booted a real virtual machine on OpenStack and logged into it — the cloud equivalent of “hello world”. From here you can layer on persistent storage with Cinder volumes, tighten access with security groups and keypairs, and automate the whole flow.

This is the same self-service experience clouditiv puts in front of teams through a managed dashboard and API on top of OpenStack 2025.2 — minus the work of building and operating the platform. Explore how that feels on our cloud dashboard.