Eine KVM-VM über die CLI hochziehen

Die allererste KVM-Virtual-Machine, die man erstellt, läuft fast immer über eine grafische Oberfläche (GUI). Ob das nun virt-manager, Cockpit oder das Web-Interface von Proxmox ist – man klickt sich brav durch Festplattengrößen, Netzwerk-Bridges und ISO-Auswahlen. Das ist ein absolut legitimer Weg, um visuell zu lernen, was all diese Optionen eigentlich bedeuten.

Aber sobald man regelmäßig VMs erstellt, wird die GUI augenblicklich zum langsamsten Teil des gesamten Prozesses. Es ist eine ermüdende Abfolge von manuellen Klicks, die jedes einzelne Mal auf exakt dieselbe Art und Weise passieren muss. Und "jedes einzelne Mal auf exakt dieselbe Art und Weise" ist buchstäblich genau das, wofür die Kommandozeile (Command Line) gebaut wurde.

Die zwei Bausteine: Ein Base-Image und Cloud-Init

Anstatt manuell eine Installer-ISO zu booten und mich durch einen langsamen OS-Installationsbildschirm zu klicken, starte ich immer mit einem Cloud-Image. Das sind exakt dieselben minimalen, vorinstallierten Images, die auch die großen Cloud-Provider verwenden. Anschließend lasse ich Cloud-Init die komplette Konfiguration beim ersten Start (First-Boot) übernehmen:

# Ein Cloud-Image genau einmal herunterladen
wget https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img \
  -O /var/lib/libvirt/images/ubuntu-24.04-base.img

Die Konfiguration von Cloud-Init besteht lediglich aus zwei kleinen YAML-Dateien. Die user-data-Datei richtet automatisch den Hauptbenutzer ein, injiziert Ihren SSH-Key und führt alle Kommandos für den ersten Start aus:

# user-data
#cloud-config
hostname: app-01
users:
  - name: deploy
    sudo: ALL=(ALL) NOPASSWD:ALL
    groups: sudo
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... your-key-here
package_update: true
packages:
  - curl
  - git

Die meta-data-Datei benötigt lediglich eine Instance-ID und den Hostnamen:

# meta-data
instance-id: app-01
local-hostname: app-01

Diese beiden winzigen Textdateien werden dann sauber in eine sehr kleine ISO verpackt, die Cloud-Init beim allerersten Start nativ einlesen kann:

genisoimage -output app-01-seed.iso -volid cidata -joliet -rock user-data meta-data

Die VM erstellen

Nachdem das Base-Image herüberkopiert und die Seed-ISO sauber gebaut wurde, erstellt und startet virt-install die VM tatsächlich mit einem einzigen, mächtigen Befehl:

cp /var/lib/libvirt/images/ubuntu-24.04-base.img /var/lib/libvirt/images/app-01.qcow2
qemu-img resize /var/lib/libvirt/images/app-01.qcow2 40G

virt-install \
  --name app-01 \
  --memory 4096 \
  --vcpus 2 \
  --disk /var/lib/libvirt/images/app-01.qcow2,format=qcow2,bus=virtio \
  --disk app-01-seed.iso,device=cdrom \
  --os-variant ubuntu24.04 \
  --network bridge=br0,model=virtio \
  --import \
  --noautoconsole

Das Flag --import sagt virt-install explizit, dass es das bestehende Festplatten-Image direkt booten soll, anstatt quälend langsam einen Installer auszuführen. Das Flag --noautoconsole gibt die Kontrolle sofort wieder an Ihr Terminal zurück, anstatt nervigerweise ein Konsolenfenster zu öffnen.

Innerhalb von ein bis zwei Minuten ist die VM vollständig hochgefahren. Cloud-Init hat den Benutzer deploy mitsamt dem exakten SSH-Key aus der user-data bereits angelegt, und:

ssh deploy@<vm-ip>

...funktioniert einfach sofort. Es gibt keine manuelle Betriebssystem-Installation, kein Durchklicken durch einen Setup-Assistenten und absolut keinen Zwang mehr, sich daran erinnern zu müssen, den SSH-Key danach noch manuell hinzuzufügen.

Warum sich das selbst für Einmal-VMs (One-Offs) lohnt

Der offensichtlichste Vorteil hierbei ist, dass es vollständig skriptbar ist. Packen Sie das Ganze in eine simple Shell-Funktion oder einen Ansible-Task, und das Hochziehen einer neuen VM ist plötzlich nur noch ein einziger Befehl, der lediglich einen Hostnamen als Argument verlangt.

Aber selbst für eine VM, die man wirklich nur ein einziges Mal braucht, gibt es einen wesentlich unscheinbareren, aber gewaltigen Vorteil: Die gesamte Konfiguration (Hostname, Benutzer, Basis-Pakete, SSH-Key) liegt sauber in zwei kleinen Textdateien vor, die direkt ins exakt selbe Git-Repo wandern können wie alles andere auch.

Wenn Sie sechs Monate später verzweifelt genau diese VM neu aufbauen müssen oder einfach nur wissen wollen, was genau darauf eigentlich installiert war, lautet die Antwort nicht: "Irgendwas, worauf ich damals grob geklickt habe". Die Antwort lautet: Zwei hochgradig lesbare Dateien, die Sie in exakt dreißig Sekunden überprüfen können.