Golden Images ohne Cloud-Init: VM-Templates für Proxmox und vSphere mit Packer

Inhaltsverzeichnis

VM-Template-Pipeline mit Packer für Proxmox und vSphere

TL;DR: vm-factory baut mit HashiCorp Packer reproduzierbare VM-Templates für Proxmox VE und VMware vSphere aus einer gemeinsamen Konfiguration – bewusst ohne Cloud-Init. Ein Build dauert rund fünf Minuten. Ergebnis: ein fertiges Image mit SSH-Key und eth0 per DHCP. Klonen, starten, als root rein. Code offen auf github.com/styliteag/vm-factory.

Warum vm-factory

Stylite betreibt VMs parallel auf Proxmox VE und VMware vSphere. Beide brauchen gute Basis-Templates zum Klonen. Für vSphere gibt es etablierte Wege, für Proxmox fehlten sie: chef/bento baut keine Proxmox-Templates, und die kursierenden Helfer-Skripte passten nicht. Also wurde vm-factory gebaut – ein schlankes Packer-Projekt, das aus einer Konfiguration Templates für beide Plattformen erzeugt. Ein Builder pro Plattform, der Rest – Provisionierung, autoinstall/preseed, Skripte – ist geteilt.

Ohne Cloud-Init – mit Absicht

Cloud-Init ist für ephemere Cloud-Instanzen und Autoscaling gebaut, und dort ist es richtig. Für ein langlebiges, selbst betriebenes Template ist es das falsche Werkzeug:

Determinismus. Ein Golden Image soll ein eingefrorenes, build-festes Artefakt sein. Cloud-Init verlagert Konfiguration in den ersten Boot und macht sie laufzeitabhängig – Datasource-Discovery, Netzwerk-Timing, Modul-Reihenfolge.
Eigentum am First Boot. Cloud-Init will Hostname, IP und Keys bei jedem Boot verwalten. Genau das macht Stylite selbst – per Ansible oder von Hand. Zwei Instanzen, die um dieselbe Konfiguration konkurrieren, sind eine vermeidbare Fehlerquelle.

Das Template bringt deshalb nur Festes mit. Alles Variable kommt danach durch eigenes Tooling.

Was im Template steckt

Ubuntu 26.04 LTS (autoinstall) und Debian 13 „Trixie” (preseed)
UEFI-Firmware auf beiden Plattformen
Gast-Tools je Ziel: qemu-guest-agent (Proxmox), open-vm-tools (vSphere) – damit die Gast-IP gefunden wird
feste Grundeinstellungen: Zeitzone, Locale, Tastatur
Interface eth0 per DHCP
root-SSH-Key aus einem gepflegten Team-Set, Login key-only
Root-Partition wächst beim ersten Boot automatisch auf die volle Plattengröße – Ubuntu (Plain) und Debian (LVM), ohne manuelles growpart/resize2fs

Verifiziert mit Packer 1.15.4, Proxmox-Plugin 1.2.3, Ubuntu 26.04 LTS und Debian 13.5.

Bauen

git clone git@github.com:styliteag/vm-factory.git
cd vm-factory

sudo ./install-packer.sh        # offizielles HashiCorp-APT-Repo (Linux)
cp credentials.pkrvars.hcl.example credentials.pkrvars.hcl
$EDITOR credentials.pkrvars.hcl  # API-URL, Token, Storage, Bridge

./build.sh validate             # Konfiguration prüfen (kein Build)
./build.sh ubuntu-26.04         # Template bauen (Default: Proxmox)

VMware läuft mit vorangestellter Plattform und eigener Credentials-Datei:

./build.sh vsphere validate
./build.sh vsphere debian-13
./build.sh vsphere all          # beide OS nacheinander

Klonen

Kein Zwischenschritt, keine Datasource, kein Warten auf einen First-Boot-Agenten:

qm clone <TEMPLATE_VMID> 9001 --name web01 --full
qm set 9001 --memory 4096 --cores 4
qm start 9001
# Klon holt sich per DHCP eine IP auf eth0; danach direkt als root:
ssh root@<IP-des-Klons>

Ab hier übernimmt das eigene Tooling: Hostname und – wo nötig – statische IP, per Ansible oder von Hand. Im Klon liegt /root/SETUP.md mit fertigen Rezepten (Hostname, feste IP für netplan/ifupdown, zweite Platte); die MOTD verweist beim Login darauf. Diese Templates sind bei Stylite die Basis für viele Projekte – mit oder ohne Ansible.

Trade-offs

DHCP im Zielnetz vorausgesetzt – sonst statische Konfiguration im Template hinterlegen.
Provisionierung ist ein zweiter Schritt – keine Per-Instance-Config beim Klonen „out of the box”.
root-SSH-Key-Modell – key-only, klar und auditierbar, aber das Team-Key-Set muss gepflegt werden.
Templates altern – Updates landen erst mit dem nächsten Build im Image. Bei fünf Minuten pro Build kein Aufwand.

Für echten Cloud-Charakter – kurzlebige Instanzen, Autoscaling, Per-Boot-Identität – bleibt Cloud-Init die bessere Wahl. vm-factory ist für den anderen Fall: langlebige VMs auf eigener Infrastruktur.

Fazit

vm-factory schließt die Proxmox-Lücke, die bento offen ließ, und behandelt vSphere gleichberechtigt aus derselben Konfiguration. Der Verzicht auf Cloud-Init ist die Designentscheidung, kein Mangel: ein deterministisches Image, das man klont, startet und sofort erreicht.

Das Projekt ist Open Source: github.com/styliteag/vm-factory.

Für Fragen zu reproduzierbaren VM-Templates, Proxmox- oder vSphere-Automatisierung stehen die Kolleginnen und Kollegen der Stylite AG gerne zur Verfügung.

Wim Bonis ist CTO der Stylite AG und beschäftigt sich schwerpunktmäßig mit Virtualisierung, Infrastruktur-Automatisierung und Open-Source-Technologien.