Eine Instanz zu starten ist der Moment, in dem sich OpenStack nicht mehr wie eine abstrakte Sammlung von Diensten anfühlt, sondern wie eine Cloud. Nova, der Compute-Dienst, nimmt einige Eingaben entgegen – ein Image, einen Flavor, ein Netzwerk, ein Keypair und eine Security-Group – und plant daraus eine virtuelle Maschine auf einem Hypervisor. Das ist die Self-Service-Erfahrung, die Public Clouds bekannt gemacht haben – auf Ihrer eigenen Hardware.

In diesem Tutorial sammeln Sie diese Bausteine und starten Ihre erste Instanz vollständig über die OpenStack-CLI, um sich anschließend per SSH zu verbinden. Es setzt eine funktionierende Cloud und einen projektbezogenen Benutzer voraus, wie in OpenStack-Projekt & Benutzer anlegen eingerichtet.

Voraussetzungen

• Eine laufende OpenStack-2025.2-Cloud mit installiertem openstack-Client.
• Projektbezogene Zugangsdaten in Ihrer Shell gesourct (Ihre openrc).
• Mindestens ein Image in Glance und ein vom Projekt erreichbares externes/Provider-Netz. Letzteres behandelt Neutron-Netze, Router und Floating IPs.

Schritt 1: Verfügbares erfassen

Listen Sie vor dem Start die vier Zutaten auf, die Nova benötigt. Das bestätigt zugleich Ihre Zugangsdaten und Quotas:

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

Ein Flavor definiert die virtuelle Hardware – vCPUs, RAM und Root-Disk. Ein Image ist die Betriebssystemvorlage. Ist Ihre Cloud frisch, haben Sie evtl. nur das Cirros-Testimage; für einen ersten Start genügt das.

Schritt 2: Ein Image hochladen (falls nötig)

Um etwas Nützlicheres als Cirros zu betreiben, laden Sie ein Cloud-Image herunter und nach Glance hoch. Cloud-Images sind so vorbereitet, dass sie SSH-Keys akzeptieren und beim ersten Start cloud-init ausführen.

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

Schritt 3: Ein Keypair erstellen

Cloud-Images haben keine Passwörter; Sie melden sich mit einem SSH-Key an, den cloud-init beim Start injiziert. Erstellen Sie ein Keypair und bewahren Sie den privaten Teil sicher auf. Sie können OpenStack eines generieren lassen oder Ihren vorhandenen öffentlichen Schlüssel hochladen:

openstack keypair create mykey > ~/.ssh/mykey.pem
chmod 600 ~/.ssh/mykey.pem
Oder einen vorhandenen Public Key hochladen:
openstack keypair create --public-key ~/.ssh/id_ed25519.pub mykey

Schritt 4: SSH per Security-Group erlauben

Standardmäßig blockiert die Security-Group sämtlichen eingehenden Verkehr. Fügen Sie eine Regel hinzu, die SSH erlaubt, damit Sie die Instanz erreichen. Security-Groups behandelt ausführlich OpenStack Security Groups & Keypairs; für den Moment genügt eine Regel:

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

Schritt 5: Die Instanz starten

Kombinieren Sie nun alles in einem einzigen server create-Befehl. Wählen Sie einen Flavor und das anzubindende Netzwerk, referenzieren Sie Keypair und Security-Group und geben Sie der Instanz einen Namen:

openstack server create 

--flavor m1.small 

--image ubuntu-24.04 

--network acme-net 

--security-group default 

--key-name mykey 

--wait 

web-01

Das Flag --wait hält den Befehl an, bis Nova die Instanz als ACTIVE oder ERROR meldet. Beobachten Sie das Statusfeld; ein gesunder Start sieht so aus:

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

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

Schritt 6: Floating IP zuweisen und verbinden

Die Instanz hat eine private Adresse im Tenant-Netz. Um sie von außen zu erreichen, weisen Sie eine Floating IP aus dem externen Netz zu und verknüpfen sie:

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

Der Standard-Login-Benutzer hängt vom Image ab – ubuntu bei Ubuntu-Cloud-Images, cirros bei Cirros, centos oder cloud-user bei anderen.

Verifizierung

Bestätigen Sie die Gesundheit der Instanz sowohl von der Control Plane als auch innerhalb der VM. Das Konsolen-Log ist unbezahlbar: Es zeigt den Boot-Ablauf und ob cloud-init Ihren Schlüssel eingespielt hat:

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

in der VM:
uptime && ip a

Häufige Fehler und Fehlersuche

Status ist direkt nach der Erstellung ERROR

Der Scheduler konnte die Instanz nicht platzieren. Lesen Sie den Fehler direkt mit openstack server show web-01 -c fault. Typische Ursachen sind kein Host mit genügend RAM/CPU (No valid host was found) oder eine erschöpfte Quota – prüfen mit openstack quota show.

Instanz ist ACTIVE, aber SSH läuft in einen Timeout

Fast immer ein Netzwerk- oder Security-Group-Problem. Prüfen Sie, dass die SSH-Regel existiert, die Floating IP verknüpft ist und ein Router Ihr Tenant-Netz mit dem externen verbindet. Das Konsolen-Log verrät, ob die VM selbst korrekt gebootet hat.

Permission denied (publickey)

Der Schlüssel wurde nicht injiziert, meist weil Sie ein Nicht-Cloud-Image gebootet haben oder cloud-init scheiterte. Nutzen Sie ein echtes Cloud-Image, prüfen Sie, dass --key-name gesetzt war, und sehen Sie im Konsolen-Log nach cloud-init-Fehlern.

Aufräumen

Löschen Sie die Instanz und geben Sie die Floating IP frei, wenn Sie fertig sind, um keine Quota zu verschwenden:

openstack server delete web-01
openstack floating ip delete 203.0.113.50

Fazit

Sie haben eine echte virtuelle Maschine auf OpenStack gestartet und sich angemeldet – das Cloud-Pendant zu „Hello World“. Von hier aus können Sie persistenten Speicher mit Cinder-Volumes ergänzen, den Zugriff mit Security Groups und Keypairs verfeinern und den gesamten Ablauf automatisieren.

Genau diese Self-Service-Erfahrung stellt clouditiv Teams über ein gemanagtes Dashboard und eine API auf Basis von OpenStack 2025.2 bereit – ohne die Arbeit, die Plattform selbst zu bauen und zu betreiben. Wie sich das anfühlt, zeigt unser Cloud-Dashboard.