Proxmox-Vorlagen mit Cloud-Init: neue VMs in einer Minute

Eine Debian-Installation von der ISO dauert eine Viertelstunde und besteht zu großen Teilen aus denselben Antworten. Die großen Distributionen veröffentlichen fertige Cloud-Images: bereits installierte, schlanke Systeme, die beim ersten Start über Cloud-Init ihren Benutzer, ihre SSH-Schlüssel und ihr Netz bekommen. Proxmox unterstützt das direkt. Einmal als Vorlage eingerichtet, ist eine neue VM ein Klon plus drei Einstellungen.

Das Cloud-Image holen#

Auf dem Proxmox-Knoten:

cd /var/lib/vz/template
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2
wget https://cloud.debian.org/images/cloud/trixie/latest/SHA512SUMS
sha512sum -c SHA512SUMS --ignore-missing

Debian bietet mehrere Varianten an. genericcloud ist für virtuelle Maschinen gedacht und verzichtet auf Treiber für echte Hardware; generic bringt sie mit. Für Proxmox-VMs ist genericcloud die schlankere Wahl.

Die Vorlage bauen#

Die ID 9000 ist eine Konvention, damit Vorlagen in der Liste unten stehen. Speicher und Bridge passt du an deine Umgebung an.

qm create 9000 --name debian13-vorlage --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26

# Image als Platte importieren und einhängen
qm set 9000 --scsi0 local-lvm:0,import-from=/var/lib/vz/template/debian-13-genericcloud-amd64.qcow2

# Cloud-Init-Laufwerk, Bootreihenfolge, serielle Konsole, Gast-Agent
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
qm set 9000 --agent enabled=1

qm template 9000

Die serielle Konsole ist bei Cloud-Images wichtig. Viele erwarten eine serielle Schnittstelle; ohne sie bleibt die Konsole in der Weboberfläche schwarz, obwohl die VM läuft.

Cloud-Init-Einstellungen#

Was die VM beim ersten Start bekommt, stellst du in der Weboberfläche unter Cloud-Init ein oder auf der Kommandozeile. An der Vorlage gesetzt, erben es alle Klone.

qm set 9000 --ciuser admin
qm set 9000 --sshkeys ~/.ssh/authorized_keys     # Datei mit öffentlichen Schlüsseln
qm set 9000 --ipconfig0 ip=dhcp
qm set 9000 --nameserver 1.1.1.1 --searchdomain example.internal

Für eine feste Adresse statt DHCP:

qm set 101 --ipconfig0 ip=10.10.10.21/24,gw=10.10.10.1

Kein Passwort, nur Schlüssel

Cloud-Init kann auch ein Passwort setzen (--cipassword). Lass es weg. Ein Klon mit Schlüsselanmeldung ist vom ersten Start an sicherer als einer, dessen Passwort in der Vorlagenkonfiguration steht. Wie es danach weitergeht, steht in Die erste Stunde auf einem neuen Server.

Den Gast-Agenten mitliefern#

Das genericcloud-Image bringt den QEMU-Gast-Agenten nicht mit. Ohne ihn zeigt Proxmox keine IP-Adressen der VM an, und Sicherungen können das Dateisystem nicht einfrieren. Cloud-Init kann ihn beim ersten Start installieren, über ein eigenes Snippet.

Zuerst dem Speicher local erlauben, Snippets aufzunehmen:

pvesm set local --content iso,vztmpl,backup,snippets
mkdir -p /var/lib/vz/snippets

# /var/lib/vz/snippets/vendor-agent.yaml
#cloud-config
packages:
  - qemu-guest-agent
runcmd:
  - systemctl enable --now qemu-guest-agent

qm set 9000 --cicustom "vendor=local:snippets/vendor-agent.yaml"

vendor statt user ist Absicht: Die Einstellungen aus der Weboberfläche (Benutzer, Schlüssel, Netz) bleiben erhalten, das Snippet kommt nur dazu.

Einen Klon erzeugen#

qm clone 9000 101 --name web01 --full
qm resize 101 scsi0 +18G          # Cloud-Images sind klein, meist 2–3 GB
qm set 101 --memory 4096 --cores 2
qm start 101

--full oder verknüpfter Klon? Ein verknüpfter Klon (ohne --full) teilt sich die Grundplatte mit der Vorlage und ist sofort da, hängt aber für immer an ihr: Die Vorlage lässt sich dann nicht mehr löschen oder ändern. Für langlebige Server ist der volle Klon die bessere Wahl.

Die Vergrößerung übernimmt Cloud-Init beim ersten Start selbst: Partition und Dateisystem wachsen auf die neue Plattengröße. Prüfen:

qm guest cmd 101 network-get-interfaces    # funktioniert, sobald der Agent läuft
ssh admin@<ip> df -h /

Die Vorlage aktuell halten#

Eine Vorlage altert. Ein Klon von einem Image, das ein halbes Jahr alt ist, startet mit einem halben Jahr an Updates im Rückstand. Zwei Wege:

Neu bauen: Image neu herunterladen, Vorlage neu anlegen. Am saubersten, und mit den Befehlen oben ein Skript von zwanzig Zeilen.
Updates beim Start: package_update: true und package_upgrade: true in das Vendor-Snippet. Der erste Start dauert dann länger, der Klon ist aber aktuell.

Häufige Fragen#

Die VM startet, aber ich komme nicht per SSH rein.#

Meist fehlt der Schlüssel oder Cloud-Init lief nicht. In der seriellen Konsole zeigt cloud-init status --long den Zustand, /var/log/cloud-init.log die Einzelheiten. Häufige Ursache: Die Cloud-Init-Einstellungen wurden nach dem ersten Start geändert, ohne danach Regenerate Image zu klicken.

Funktioniert das auch mit Ubuntu oder anderen Distributionen?#

Ja. Ubuntu, AlmaLinux, Rocky und Fedora veröffentlichen ebenfalls Cloud-Images. Nur der Download-Pfad unterscheidet sich.

Und für Container?#

LXC-Container haben ihre eigenen Vorlagen über pveam. Cloud-Init brauchen sie nicht. Wann welcher Typ passt, steht in LXC oder VM?.

Kann ich das mit Terraform oder Ansible verbinden?#

Ja, beide können Proxmox-Klone mit Cloud-Init-Werten anlegen. Die Vorlage aus diesem Beitrag ist dafür die Grundlage.

Kurz gesagt#

Cloud-Images sind fertig installierte Systeme; Cloud-Init setzt beim ersten Start Benutzer, Schlüssel und Netz.
Vorlage: importieren, Cloud-Init-Laufwerk, serielle Konsole, Agent aktivieren, qm template.
Den Gast-Agenten über ein vendor-Snippet nachinstallieren.
Volle Klone für langlebige Server, dann qm resize für die echte Plattengröße.
Die Vorlage regelmäßig neu bauen, sonst startet jeder Klon veraltet.