Proxmox VM-Templates vs. Cloud-Init: Wann was?

Wer in Proxmox VE 8.x regelmäßig neue virtuelle Maschinen ausrollt, steht früher oder später vor der Frage: Setze ich auf klassische VM-Templates mit Linked Clones — oder auf Cloud-Init-basierte Provisionierung? Beide Ansätze sind offiziell unterstützt, beide funktionieren zuverlässig, und beide haben in der Praxis ihre eigene Zielgruppe. Die Wahl entscheidet nicht nur über den Storage-Bedarf, sondern auch darüber, wie schnell Ihr Team auf Sicherheits-Patches reagieren kann und wie sauber sich das Ganze in eine IaC-Pipeline einbetten lässt.

In diesem Artikel zeigen wir Ihnen, wie beide Muster funktionieren, wo die technischen Grenzen liegen und in welchen Szenarien wir bei unseren Kundenprojekten den einen oder anderen Weg empfehlen.

Zwei Muster, zwei Philosophien

Ein VM-Template ist in Proxmox nichts anderes als eine VM, die per qm template <vmid> in einen schreibgeschützten Zustand versetzt wurde. Ab diesem Moment kann sie nicht mehr gestartet, aber beliebig oft geklont werden — entweder als Full Clone (vollständige Kopie) oder als Linked Clone (Delta-Layer auf der Template-Disk). Templates entsprechen dem Konzept der immutable base images: Sie werden einmal sauber gebaut, gehärtet, gepatcht und danach nicht mehr verändert.

Cloud-Init hingegen ist ein herstellerübergreifender Standard aus der Public-Cloud-Welt (Canonical, ursprünglich für Ubuntu auf EC2). Proxmox unterstützt Cloud-Init über eine spezielle CD-ROM-artige Disk, die einer generischen Cloud-Image-VM Metadaten mitgibt: Hostname, IP-Adresse, SSH-Keys, User, Netzwerkkonfiguration und optional komplette user-data-Skripte. Die Basis-Disk bleibt generisch, die individuelle Konfiguration entsteht erst beim ersten Boot.

Kurz gesagt: Templates definieren was drin ist, Cloud-Init definiert wie es sich einrichtet. In vielen professionellen Setups kombinieren wir beide Ansätze.

Muster 1: Klassisches Template mit Linked Clone

Der klassische Weg eignet sich hervorragend für Umgebungen, in denen viele VMs vom selben Basis-Image profitieren — etwa VDI, RDS-Farmen oder homogene Windows-Server-Fleets. Der Ablauf ist überschaubar:

# 1. Basis-VM installieren, härten, patchen
qm create 9000 --name tpl-debian12-base --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single
qm importdisk 9000 debian-12-generic-amd64.qcow2 local-zfs
qm set 9000 --scsi0 local-zfs:vm-9000-disk-0,discard=on,ssd=1
qm set 9000 --boot order=scsi0 --agent enabled=1

# 2. VM starten, konfigurieren, herunterfahren
# 3. In Template konvertieren
qm template 9000

# 4. Linked Clone erzeugen
qm clone 9000 101 --name web01 --full 0

Der Parameter --full 0 erzeugt einen Linked Clone: Die neue VM verweist auf die Template-Disk und speichert nur Änderungen als Delta. Vorteil: Ein Klon ist in Sekunden erstellt und belegt initial nur wenige MB. Nachteil: Alle Klone hängen dauerhaft am Template. Wird das Template gelöscht, sind alle Kinder unbrauchbar. Ein “Refresh” auf ein neueres Basis-Image erfordert das Ausrollen komplett neuer VMs.

Muster 2: Cloud-Init-Provisionierung

Cloud-Init entfaltet seine Stärken dort, wo VMs sich in Netzwerk, Hostname, Zertifikaten oder User-Setup unterscheiden — also praktisch immer, wenn Sie Linux-Workloads dynamisch ausrollen. Statt ein selbstgebautes Image zu pflegen, laden Sie das offizielle Cloud Image der Distribution herunter (Debian, Ubuntu, Rocky, AlmaLinux stellen diese bereit) und binden eine Cloud-Init-Drive an:

# Cloud-Image importieren
qm create 9100 --name tpl-ubuntu2404-ci --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --serial0 socket
qm importdisk 9100 noble-server-cloudimg-amd64.img local-zfs
qm set 9100 --scsi0 local-zfs:vm-9100-disk-0,discard=on,ssd=1
qm set 9100 --ide2 local-zfs:cloudinit
qm set 9100 --boot order=scsi0 --agent enabled=1
qm template 9100

# Klonen und pro VM individualisieren
qm clone 9100 201 --name db01 --full 1
qm set 201 --ipconfig0 ip=10.10.20.11/24,gw=10.10.20.1
qm set 201 --sshkeys ~/.ssh/authorized_keys
qm set 201 --ciuser admin --cipassword $(openssl passwd -6 'geheim')
qm start 201

Für komplexere Setups (Pakete nachinstallieren, Systemd-Units aktivieren, /etc/hosts befüllen) hinterlegen Sie eine user-data-Datei als Snippet:

#cloud-config
package_update: true
package_upgrade: true
packages:
  - qemu-guest-agent
  - htop
  - fail2ban
runcmd:
  - systemctl enable --now qemu-guest-agent
  - systemctl enable --now fail2ban
write_files:
  - path: /etc/motd
    content: |
      Managed by DATAZONE -- unauthorized access prohibited.

Die Datei legen Sie unter /var/lib/vz/snippets/user-data-db.yaml ab und referenzieren sie:

qm set 201 --cicustom "user=local:snippets/user-data-db.yaml"

Direkter Vergleich

Kriterium	VM-Template + Linked Clone	Cloud-Init
Klonzeit	Sekunden	Sekunden bis Minuten (First-Boot-Setup)
Storage-Overhead	Sehr niedrig (Delta)	Voller Klon üblich, Thin Provisioning möglich
Individualisierung pro VM	Nachträglich manuell/per Skript	Deklarativ im Clone-Befehl
Patch-Refresh	Neues Template + Neuausrollen	apt upgrade im laufenden Betrieb
Kopplung an Basis	Hart — Template darf nicht weg	Lose — Basis-Image austauschbar
Windows-Unterstützung	Sehr gut (Sysprep)	Eingeschränkt (Cloudbase-Init nötig)
IaC-Freundlichkeit	Mittel	Sehr gut (Terraform, Ansible, Packer)
Ideal für	VDI, homogene Fleets, gehärtete Images	Linux-Server, DevOps, Multi-Tenant

Wann welches Muster? Unsere Empfehlung

Templates mit Linked Clones empfehlen wir, wenn Sie:

• viele nahezu identische VMs benötigen (z.B. VDI-Pool, Terminalserver-Farm),
• ein durch Sie kontrolliertes, gehärtetes Basis-Image pflegen wollen (Stichwort CIS-Benchmark),
• Storage-Effizienz auf ZFS oder LVM-Thin maximieren müssen,
• klassische Windows-Workloads mit Sysprep-Vorbereitung ausrollen.

Cloud-Init ist unsere Empfehlung, wenn Sie:

• Linux-Server dynamisch mit individueller IP, Hostname und Paketauswahl provisionieren,
• Terraform, Ansible oder Packer als Automatisierungsschicht einsetzen,
• häufige Refresh-Zyklen der Basis-Images wollen (Ubuntu LTS, Debian Stable),
• Multi-Tenant-Szenarien mit unterschiedlichen SSH-Keys pro Kunde bedienen.

In der Praxis kombinieren wir beides: Ein selbst gebautes Cloud-Init-Template (mit Packer erzeugt, gehärtet, mit qemu-guest-agent und Monitoring-Agent) dient als Basis, und die individuelle Konfiguration wandert in user-data-Snippets, die aus einem Git-Repo verwaltet werden. So bekommen Sie die Storage-Effizienz und Kontrolle der Template-Welt mit der deklarativen Flexibilität von Cloud-Init.

Häufige Stolperfallen

• QEMU Guest Agent nicht aktiviert: Ohne --agent enabled=1 und installierten Agent im Gast funktionieren qm shutdown, IP-Anzeige und Snapshot-Freeze nicht sauber.
• Cloud-Init cached alte Konfiguration: Bei erneutem Anpassen von Netzwerk oder User müssen Sie im Gast cloud-init clean ausführen oder besser gleich neu klonen.
• Linked Clones und Storage-Migration: Ein Linked Clone lässt sich nicht ohne weiteres auf einen anderen Storage verschieben — planen Sie das im Storage-Design mit ein.
• Template-Updates: Ein “Update” eines Templates gibt es nicht. Bauen Sie ein neues Template mit inkrementierter Versionsnummer (tpl-debian12-base-v3) und rollen Sie neue VMs davon aus.

Fazit

Beide Muster haben ihre Berechtigung, und die Frage ist selten “entweder oder”, sondern “wofür welches”. Wer VDI und homogene Windows-Fleets betreibt, kommt an klassischen Templates mit Linked Clones nicht vorbei. Wer eine moderne Linux-Server-Landschaft dynamisch provisioniert, ist mit Cloud-Init deutlich schneller und automatisierungsfreundlicher unterwegs. Und wer beides kombiniert, holt aus Proxmox VE das Maximum an Effizienz und Flexibilität heraus.

DATAZONE unterstützt Sie beim Design von Proxmox-Provisionierungsstrecken, beim Aufbau reproduzierbarer Packer-Pipelines für Linux-Basis-Images und bei der Integration in Terraform oder Ansible. Ob Greenfield-Cluster oder Migration bestehender ESXi-Landschaften — sprechen Sie uns an unter kontakt@datazone.de und wir bauen mit Ihnen die Provisionierungsstrecke, die zu Ihrem Team und Ihrem Change-Rhythmus passt.