[ OK ]Kernel wird initialisiert...
~/im/blog
Kontakt aufnehmen

Lass uns reden

Interesse an einer Zusammenarbeit oder eine Frage? Ich bin immer offen für neue Projekte.

Kontakt aufnehmen

Vernetzen

Finden Sie mich in sozialen Medien und auf beruflichen Netzwerken.

DatenschutzerklärungNutzungsbedingungen
© 2026 Irfan MiralEntwickelt vonirfanMiral.com
StartÜber mich/LebenslaufBlogKontakt
2026-04-16• 5 Min. Lesezeit

Eine KVM-VM von der Kommandozeile aus aufsetzen

Cloud KVM Virtualisierung Linux-Administration

Die erste KVM-VM, die jemand erstellt, läuft fast immer über eine grafische Oberfläche, virt-manager, Cockpit oder das Proxmox-Webinterface, mit Klicks durch Disk-Größe, Netzwerk und ISO-Auswahl. Das ist eine gute Art zu lernen, was die Optionen bedeuten. Aber sobald man regelmäßig VMs anlegt, wird die GUI zum langsamen Teil: eine Abfolge von Klicks, die jedes Mal gleich ablaufen muss, und "jedes Mal gleich" ist genau das, wofür eine Kommandozeile gemacht ist.

Die zwei Bausteine: ein Basis-Image und Cloud-Init

Statt ein Installer-ISO zu booten und sich durch eine Betriebssysteminstallation zu klicken, starte ich von einem Cloud-Image, denselben minimalen, vorinstallierten Images, die auch Cloud-Provider verwenden, und lasse Cloud-Init die Konfiguration beim ersten Boot übernehmen:

# Cloud-Image einmalig 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 Cloud-Init-Konfiguration besteht aus zwei kleinen YAML-Dateien. user-data legt den Benutzer, den SSH-Key und etwaige First-Boot-Befehle fest:

# 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... dein-key-hier
package_update: true
packages:
  - curl
  - git

meta-data braucht nur eine Instanz-ID und einen Hostnamen:

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

Daraus wird ein kleines ISO gebaut, das Cloud-Init beim ersten Boot liest:

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

Die VM erstellen

Mit dem kopierten Basis-Image und dem gebauten Seed-ISO erstellt und startet virt-install die VM in einem 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

--import sagt virt-install, das vorhandene Disk-Image direkt zu booten, statt einen Installer auszuführen, und --noautoconsole gibt das Terminal zurück, statt ein Konsolenfenster zu öffnen. Innerhalb von ein, zwei Minuten läuft die VM, Cloud-Init hat den Benutzer deploy mit dem SSH-Key aus user-data angelegt, und:

ssh deploy@<vm-ip>

funktioniert einfach, keine manuelle OS-Installation, kein Durchklicken eines Assistenten, kein nachträgliches Hinterlegen des SSH-Keys.

Warum sich das auch für eine einzelne VM lohnt

Der naheliegende Vorteil ist, dass das skriptbar ist, in eine Shell-Funktion oder eine Ansible-Task verpackt wird eine neue VM zu einem einzelnen Befehl mit Hostname als Argument. Aber selbst für eine wirklich einmalige VM gibt es einen leiseren Vorteil: Die gesamte Konfiguration, Hostname, Benutzer, Pakete, SSH-Key, steckt in zwei kleinen Textdateien, die ins selbe Git-Repo wandern können wie alles andere. Sechs Monate später, wenn man diese VM neu aufsetzen muss oder sich einfach erinnern will, was darauf installiert war, lautet die Antwort nicht "was ich noch zusammenklicken zu wissen meine", sondern zwei Dateien, die in dreißig Sekunden gelesen sind.

VorherigerProxmox-Snapshots sind keine BackupsNächster Warum ich OVH und Contabo neben AWS immer noch empfehle