Proxmox Templates + Cloud-Init: Ein Praxis-Workflow

Wer im Proxmox-Alltag regelmäßig VMs ausrollt, kennt das Ritual: ISO mounten, Installer durchklicken, SSH-Key nachtragen, Netzwerk konfigurieren, Pakete installieren. Zehn Minuten pro Maschine, wenn alles glatt läuft. Bei einem Kubernetes-Cluster mit sechs Nodes sind das schnell zwei Stunden — und jede Maschine ist minimal anders, weil sich Fingerklicks nie exakt wiederholen lassen.

Die Kombination aus Proxmox Templates und Cloud-Init löst genau dieses Problem. Statt ISO-Installer nutzen Sie die offiziellen Cloud-Images der Distributionen als goldene Basis, klonen sie in Sekunden und übergeben die instanzspezifischen Parameter — Hostname, IP, SSH-Key, User — über ein Cloud-Init-Laufwerk. Dieser Artikel zeigt den kompletten Workflow, den wir in Kundenprojekten einsetzen, und liefert das Bash-Skript, mit dem sich zehn VMs in unter 60 Sekunden ausrollen lassen.

Warum Cloud-Init statt eigenem Golden Image?

Ein klassischer Ansatz ist das selbst gepflegte Golden Image: einmal installieren, alle Pakete rauf, herunterfahren, als Template markieren. Funktioniert — bis das Image altert. Nach drei Monaten fehlen Security-Patches, Kernel-Versionen driften auseinander, und beim nächsten Update-Zyklus muss der Prozess von vorn beginnen.

Cloud-Images sind der elegantere Weg. Debian, Ubuntu, Rocky Linux, AlmaLinux und openSUSE veröffentlichen minimale, auf qcow2 optimierte Images, die von den Distributionen selbst gepflegt und wöchentlich aktualisiert werden. Sie enthalten das cloud-init-Paket bereits vorinstalliert und lesen beim ersten Boot eine Konfiguration aus einer angehängten virtuellen CD-ROM. Genau diesen Mechanismus nutzt Proxmox mit seiner integrierten Cloud-Init-Unterstützung.

Für reines Provisioning ohne Applikationslogik (Basis-OS, User, SSH, Netzwerk) reicht Cloud-Init völlig aus. Für komplexere Konfiguration — Kubernetes-Beitritt, Ansible-Bootstrap, Compliance-Baselines — kombinieren Sie Cloud-Init mit einem Post-Provisioning-Tool. Cloud-Init bringt die Maschine ans Netz und übergibt an Ansible, Salt oder ein internes Skript.

Schritt 1: Cloud-Image herunterladen und Template bauen

Der Ausgangspunkt ist ein aktuelles Cloud-Image. Für Debian 13 (Trixie) sieht das so aus — ausgeführt auf einem Proxmox-8.x-Host als root:

# Aktuelles Debian-13-Cloud-Image herunterladen
cd /var/lib/vz/template/iso
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2

# VM-Shell anlegen (ID 9000 reservieren wir konventionell fuer Templates)
qm create 9000 --name debian-13-tpl --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single

# Cloud-Image als Root-Disk importieren
qm importdisk 9000 debian-13-generic-amd64.qcow2 local-zfs

# Importierte Disk als scsi0 einhaengen und Boot-Reihenfolge setzen
qm set 9000 --scsi0 local-zfs:vm-9000-disk-0,discard=on,ssd=1
qm set 9000 --boot order=scsi0 --serial0 socket --vga serial0

# Cloud-Init-Drive als CD-ROM anlegen (Proxmox erzeugt die ISO on-the-fly)
qm set 9000 --ide2 local-zfs:cloudinit

# In Template konvertieren
qm template 9000

Wichtig sind drei Details: discard=on aktiviert TRIM/Unmap-Weitergabe, wichtig für thin-provisioned ZFS oder Ceph. serial0 sorgt dafür, dass Cloud-Images ohne Grafik-Konsole ihre Bootlogs auf die serielle Konsole schicken — ohne diesen Schritt sehen Sie beim ersten Boot einen schwarzen Bildschirm. Und virtio-scsi-single gibt jeder Disk ihren eigenen Controller, was für parallele I/O und spätere Hotplug-Operationen sauberer ist.

Schritt 2: Klonen mit Cloud-Init-Parametern

Das Template selbst wird nie gebootet. Jede produktive VM entsteht per qm clone und bekommt anschließend ihre individuellen Cloud-Init-Werte:

# Vollklon von Template 9000 zu neuer VM 101
qm clone 9000 101 --name web01 --full --storage local-zfs

# Cloud-Init-Parameter setzen
qm set 101 --ciuser deploy \
  --sshkeys ~/.ssh/authorized_keys \
  --ipconfig0 ip=10.10.20.11/24,gw=10.10.20.1 \
  --nameserver 10.10.20.1 \
  --searchdomain intern.example.de

# Disk auf gewuenschte Groesse aufblasen (Cloud-Image ist meist 2-4 GB)
qm resize 101 scsi0 +30G

# Ressourcen anpassen und starten
qm set 101 --memory 4096 --cores 4
qm start 101

Nach 15 bis 25 Sekunden ist die VM per SSH erreichbar — ohne dass Sie jemals eine Konsole gesehen hätten. Cloud-Init hat beim ersten Boot Hostname, Netzwerk, User und SSH-Key aus dem virtuellen ISO gelesen, das Filesystem auf die neue Diskgröße expandiert und sich selbst deaktiviert.

Schritt 3: Zehn VMs in unter 60 Sekunden

Der Sprung von einer VM auf zehn ist ein Bash-Loop. Das folgende Skript rollt einen Kubernetes-Worker-Pool aus:

#!/usr/bin/env bash
set -euo pipefail

TEMPLATE_ID=9000
STORAGE=local-zfs
BRIDGE=vmbr0
GW=10.10.20.1
DNS=10.10.20.1
SSH_KEYS=/root/.ssh/deploy_authorized_keys
DOMAIN=intern.example.de

for i in $(seq 1 10); do
  VMID=$((200 + i))
  IP="10.10.20.$((100 + i))"
  NAME="k8s-worker-$(printf '%02d' "$i")"

  qm clone "$TEMPLATE_ID" "$VMID" \
    --name "$NAME" --full --storage "$STORAGE" &

done
wait

for i in $(seq 1 10); do
  VMID=$((200 + i))
  IP="10.10.20.$((100 + i))"

  qm set "$VMID" \
    --ciuser deploy \
    --sshkeys "$SSH_KEYS" \
    --ipconfig0 "ip=${IP}/24,gw=${GW}" \
    --nameserver "$DNS" \
    --searchdomain "$DOMAIN" \
    --memory 8192 --cores 4
  qm resize "$VMID" scsi0 +50G
  qm start "$VMID"
done

Der Trick: Die zehn qm clone-Aufrufe laufen parallel im Hintergrund. Auf einem Host mit NVMe- oder Ceph-Storage ist ein Full-Clone eines 2-GB-Images nach wenigen Sekunden fertig — in unseren Kundenprojekten sehen wir typischerweise 40 bis 55 Sekunden vom Start des Skripts bis zum SSH-Login auf der letzten VM. Wer Linked Clones verwendet (möglich bei einigen Storage-Typen), kommt noch schneller ans Ziel, opfert aber die Unabhängigkeit vom Template.

Wann Template + Cloud-Init — und wann nicht?

Nicht jede Situation profitiert vom Cloud-Init-Ansatz. Die folgende Tabelle fasst zusammen, wann sich der Setup-Aufwand lohnt und wann andere Werkzeuge besser passen:

Szenario	Empfehlung	Grund
Wiederkehrende Linux-VMs, gleiches Muster	Template + Cloud-Init	Sekunden statt Minuten pro Rollout
Windows-VMs	Template + Sysprep + Unattended.xml	Cloud-Init unter Windows funktioniert, ist aber weniger reif
Ein einzelner Legacy-Server	Klassischer ISO-Installer	Setup-Overhead lohnt nicht
Kompletter Cluster mit App-Stack	Cloud-Init + Ansible/Terraform	Cloud-Init bootstrappt, Ansible konfiguriert
Immutable-Ansatz, viele Rebuilds	Packer + Cloud-Init	Packer baut versionierte Templates automatisiert
Sehr heterogene Workloads	Individuelle Templates pro Rolle	Weniger qm set-Parameter im Skript

In der Praxis empfehlen wir bei Proxmox-Beratung fast immer eine Zwei-Ebenen-Strategie: ein oder zwei sauber gepflegte Cloud-Init-Templates (Debian-LTS, Ubuntu-LTS, optional Rocky) plus ein Ansible-Playbook, das rollenspezifisch nachkonfiguriert. Das hält die Template-Anzahl klein, macht Updates trivial (Image tauschen, Template neu bauen) und trennt sauber zwischen OS-Provisioning und Applikationslogik.

Stolpersteine aus der Praxis

Drei Probleme sehen wir in Kundenprojekten immer wieder:

Fehlende qemu-guest-agent-Integration. Cloud-Images bringen den Agent oft nicht mit. Ergänzen Sie ihn im Template per virt-customize -a debian-13-generic-amd64.qcow2 --install qemu-guest-agent (aus dem Paket libguestfs-tools), sonst zeigt Proxmox keine IP im GUI und Backups können keine Filesystem-Freezes auslösen.

Falscher Storage-Typ für Cloud-Init-Drive. Die Cloud-Init-ISO muss auf einem Storage liegen, der snippets oder iso unterstützt. Auf reinen images-Storages (bei manchen Ceph-Pool-Konfigurationen) schlägt qm set --ide2 ... :cloudinit fehl. Lösung: einen zweiten Storage-Eintrag mit content=iso,vztmpl,snippets anlegen.

Statische IPs kollidieren nach Klon. Wenn Sie das Template testweise gebootet haben und danach nicht aufräumen, klont Proxmox die alte Machine-ID mit. Das führt zu identischen DHCP-Leases und fehlerhaftem SSH-Host-Key-Verhalten. Deshalb: Template niemals booten, immer nur klonen. Falls doch nötig — vor der Konvertierung cloud-init clean --logs und truncate -s 0 /etc/machine-id ausführen.

Fazit

Templates plus Cloud-Init verwandeln Proxmox von einem Klick-Hypervisor in eine Provisioning-Plattform. Der einmalige Aufwand für den sauberen Template-Bau — eine Stunde inklusive Test — amortisiert sich beim zweiten Rollout. Kombiniert mit Ansible oder Terraform entsteht ein reproduzierbares, versionierbares Deployment-Verfahren, das auch in kleinen IT-Abteilungen ohne dediziertes DevOps-Team funktioniert.

DATAZONE unterstützt Sie bei der Einführung dieses Workflows — vom Template-Design über die Storage- und Netzwerkarchitektur bis zur Integration in bestehende Backup- und Monitoring-Landschaften. Wenn Sie Ihre Proxmox-Umgebung aus dem manuellen Modus in eine automatisierte Infrastruktur überführen wollen, sprechen Sie uns an: Kontakt aufnehmen.