Eine VM als Vorlage erstellen

Im vorherigen Leitfaden haben Sie einen gerouteten IPv4- und einen WireGuard-Tunnel eingerichtet, sodass nun fünf Adressen über den Proxmox-Host erreichbar sind und an dessen erste VM weitergeleitet werden. Um eine zweite VM in Betrieb zu nehmen, ohne den gesamten Installationsvorgang erneut durchlaufen zu müssen, wandeln Sie zunächst die bereits laufende VM in eine wiederverwendbare Vorlage um.

Die VM in eine Vorlage umwandeln

Eine Vorlage beginnt als gewöhnliche VM, die bereits installiert, konfiguriert und auf ihre Funktionsfähigkeit überprüft wurde: dieselbe VM, die vor zwei Anleitungen erstellt wurde. Durch die Umwandlung wird genau dieser Zustand festgehalten. Sobald eine VM zu einer Vorlage wird, lässt Proxmox nicht mehr zu, dass sie eigenständig hochfährt; sie dient fortan ausschließlich als Vorlage für Klone.

Die VM muss zunächst angehalten werden, da eine Vorlage ein Festplatten-Image und nicht den laufenden Betriebszustand erfasst. Das Proxmox-eigene Panel bietet dies als einen einzigen Schritt an: Wählen Sie die angehaltene VM in der linken Baumstruktur aus, öffnen Sie oben rechts auf der Übersichtsseite den Menüpunkt „Mehr“, und ganz oben in diesem Menü finden Sie die Option „In Vorlage konvertieren“ – dasselbe Menü, das Sie auch direkt über einen Rechtsklick auf die VM in der Baumstruktur aufrufen können. Auch die dahinterstehende Befehlszeile ist wissenswert, da sie von jedem Provisioning-Skript aufgerufen wird, sobald dies nicht mehr nur eine einmalige Aktion ist:

qm template 100

Diese Umbenennung ist der eigentliche Mechanismus hinter einer Vorlage: Das Festplattenvolume selbst wird zu base-100-disk-0, eine schreibgeschützte Basis, aus der jeder zukünftige Klon standardmäßig liest, anstatt sie direkt zu kopieren.

Nein. Proxmox entfernt den Menüpunkt „Start“ vollständig aus dem Menü der Vorlage, und das Bedienfeld zeigt genau an, was an seiner Stelle verbleibt, sobald „web01“ als Vorlage erstellt wurde:

Die Option „In Vorlage konvertieren“ bleibt zwar sichtbar, ist jedoch ausgegraut – auf diese Weise bestätigt Proxmox, dass es sich bereits um eine VM handelt, anstatt die Option vollständig auszublenden. Die Baumstruktur auf der linken Seite verdeutlicht dies visuell: „web01“ behält ein einfaches Kästchen-Symbol bei, während „web02“ und „web03“, beides gewöhnliche VMs, stattdessen einen kleinen Monitorbildschirm anzeigen. Die Konfigurationsdatei bestätigt, was das Menü bereits anzeigt: eine neue Zeile, template: 1, erscheint in /etc/pve/qemu-server/100.conf zusätzlich zu allem, was bereits vorhanden ist.

Vorlage klonen

Das Klonen ist ja gerade der Sinn und Zweck der Erstellung einer VM-Vorlage. Anstatt ein neues Installationsprogramm durch die Bildschirme für Sprache, Tastatur, Partitionierung und alle anderen Schritte aus der Anleitung von vor zwei Anleitungen zu führen, erhält man mit einem Klon innerhalb von Sekunden eine laufende, identisch konfigurierte VM.

Wählen Sie einen vollständigen Klon oder einen verknüpften Klon aus

Wenn Sie im selben Menü „Mehr“ auf „Klonen“ klicken, öffnet sich kein Assistent mit acht Registerkarten, sondern ein kleines Dialogfeld: ein Zielknoten, die automatisch ausgefüllte ID der nächsten freien VM, ein Feld „Name“ und ein Dropdown-Menü „Modus“, dessen Auswahl wichtiger ist, als es auf den ersten Blick erscheint.

Die Optionen „Zielspeicher“ und „Format“, die in diesem Screenshot beide ausgegraut sind, werden erst aktiv, wenn der Modus auf „Vollklon“ umgeschaltet wird: Bei einem verknüpften Klon muss keine eigenständige Entscheidung zum Speicherort getroffen werden – er wird immer dort abgelegt, wo sich die Festplatte der Vorlage bereits befindet.

• Vollständiger Klon: Eine völlig unabhängige Kopie jedes Blocks auf der Festplatte der Vorlage, die auf dem Speichermedium, auf das der Klon kopiert wird, neu zugewiesen wird. Sobald die Kopie abgeschlossen ist, hat nichts an der Vorlage mehr Einfluss darauf – allerdings muss diese Kopie tatsächlich durchgeführt werden: Das Klonen einer 16-GiB-Festplatte auf diese Weise dauerte über eine Minute.
• Verknüpfter Klon: Ein „Thin Snapshot“, der nur die Änderungen des Klons speichert und alle unveränderten Daten direkt aus den Blöcken der Vorlage ausliest. Das Klonen derselben 16-GiB-Festplatte auf diese Weise war in weniger als zwei Sekunden abgeschlossen, da noch nichts tatsächlich kopiert wurde.

Den Klon ausführen

Abfahrt --full Wenn das Speicher-Backend dies unterstützt, wird standardmäßig ein verknüpfter Klon verwendet, was local-lvm so wird es hier gemacht. Indem man die neue VM „web02“ nennt – entsprechend dem bereits durch „web01“ vorgegebenen Schema –, bleiben die beiden einheitlich:

qm clone 100 101 --name web02

Diese beiden WARNUNG-Zeilen sollte man sich durchlesen, anstatt sie einfach zu ignorieren: Der Speicherpool dieses Labors ist tatsächlich so klein, dass Proxmox zu Recht darauf hinweist – dieselbe Warnung, die ein Produktionsknoten anzeigt, sobald genügend verknüpfte Klone vorhanden sind, um theoretisch seine eigene physische Kapazität zu überschreiten, wenn jeder einzelne von ihnen gleichzeitig in jeden Block schreiben würde. Es handelt sich um einen Hinweis zur Kapazitätsplanung, der beschreibt, was im schlimmsten Fall passieren würde – was hier durch die tatsächliche verstrichene Zeit direkt darunter als harmlos bestätigt wird.

Bestätigen Sie die Zuordnung in LVM

Die Abhängigkeit, auf die sich diese Warnung bezieht, ist direkt auf der Speicherebene sichtbar. Bei der Abfrage der logischen Volumes der Volume-Gruppe wird sie in einer einzigen Spalte angezeigt:

lvs -o lv_name,origin,lv_size pve

Diese „Origin“-Spalte ist der tatsächliche, auf Speicherebene liegende Beweis dafür, was ein verknüpfter Klon bedeutet: vm-101-disk-0 enthält noch keine eigenen Daten, abgesehen von den Änderungen, die das Gastbetriebssystem seit dem Klonen vorgenommen hat, und jeder unveränderte Block verweist weiterhin auf base-100-disk-0.

Korrigiere das, was der Klon noch mit der Vorlage gemeinsam hat

Proxmox selbst randomisiert nur das, was es direkt verwaltet: eine neue MAC-Adresse auf net0, eine neue UUID in smbios1, ein neues vmgenid. Ein direkter Vergleich der beiden Konfigurationsdateien zeigt genau das und nichts weiter:

web01 (100): net0 virtio=BC:24:11:40:09:E7   smbios1 uuid=8874d2ab-e9ec-4094-9b59-611829e70ccb
web02 (101): net0 virtio=BC:24:11:33:95:ED   smbios1 uuid=fd463a04-aa85-4015-9b6d-884d34db4b1c

Alles, was Proxmox außerhalb der Festplatte selbst erfasst, ist also bereits eindeutig. Was sich auf dieser Festplatte befindet, ist eine andere Geschichte: Der Klon ist eine bitweise Kopie des Dateisystems der Vorlage, sodass alles, was das Gastbetriebssystem selbst zur Identifizierung verwendet, unverändert übernommen wird.

Ja, und zwar auf zwei konkrete Arten. systemd-eigene machine-id, die pro Installation einzigartig sein sollen, sowie alle während der Einrichtung generierten SSH-Hostschlüssel bleiben bei einem Klon vollständig erhalten, was sich durch das Einbinden beider Festplatten im schreibgeschützten Modus und deren Vergleich eindeutig bestätigt:

Eine gemeinsam genutzte Maschinen-ID führt bei allen Systemen, die sich darauf beziehen, zu Verwirrung – von der D-Bus-eigenen Maschinenregistrierung bis hin zu einem DHCP-Client, der sie als stabile Kennung verwendet –, und ein gemeinsam genutzter Hostname macht zwei VMs aus Sicht eines Überwachungs-Dashboards nicht mehr unterscheidbar. Beides lässt sich mit wenigen Befehlen beheben, die einmalig in dem neuen Klon ausgeführt werden sollten, bevor dieser an einen Kunden ausgeliefert wird:

rm -f /etc/machine-id
systemd-machine-id-setup
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
hostnamectl set-hostname web02

Diese letzte Zeile braucht auch ihr Gegenstück in /etc/hosts, wobei der neue Hostname auf die Loopback-Adresse abgestimmt wird, so wie es der Installer bereits vor zwei Anleitungen für „web01“ eingerichtet hat.

Das Klonen für einen Vertriebs-Workflow automatisieren

Keiner der oben genannten Schritte erfordert, dass eine Person durch einen Dialog klickt, sobald sie es wert sind, für jede VM ausgeführt zu werden, die eine Plattform tatsächlich verkauft. Das Gleiche qm clone Der Befehl greift direkt auf die Proxmox-API zu – dieselbe API, die in dieser Anleitung bereits zum Erstellen einer VM und zum Abrufen einer ISO-Datei aufgerufen wurde:

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/clone" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "newid=102" \
  --data-urlencode "name=web03" \
  --data-urlencode "full=1"

Dieser Aufruf gibt sofort eine Aufgaben-ID zurück, anstatt auf den Abschluss des Klonvorgangs zu warten – dasselbe asynchrone Muster, das hinter jeder anderen lang andauernden Aktion in Proxmox steckt. Diese Aufgaben-ID hat ein festes, wiedererkennbares Format:

UPID:pve:00002FD6:000590CA:6ABB8D48:qmclone:100:root@pam:

Umfrage /nodes/pve/tasks/<that UPID>/status Genauso weiß ein Provisioning-Skript tatsächlich, wann ein vollständiger Klon – der bei einer 16-GiB-Festplatte über eine Minute dauert – abgeschlossen ist, anstatt dies anhand einer festen Verzögerung zu schätzen.

Ein vollständiges Provisioning-Skript verknüpft vier dieser Komponenten der Reihe nach miteinander: qm clone Um die VM zu erstellen, muss die machine-id und die SSH-Hostschlüssel-Befehle aus dem vorherigen Abschnitt werden dort einmal ausgeführt, es wird eine Route für die jeweilige Adresse aus dem Adresspool des Tunnels hinzugefügt, die diesem Kunden bei der Bestellung zugewiesen wurde, und schließlich qm start. Alles zwischen dem ersten Anruf und dem Erhalt funktionierender Zugangsdaten durch den Kunden läuft automatisch ab – genau die Abfolge, die ein menschlicher Mitarbeiter beim ersten Mal manuell durchgeführt hat.