VM-Lebenszyklus und Vorlagen

Der Lebenszyklus beginnt vor dem ersten Boot

Eine VM ist kein einmal kopiertes Datenträgerfile. Ihr Betriebsvertrag beginnt mit der Quelle, aus der sie entsteht, und endet erst, wenn Daten, Identitäten, Netzregistrierungen, Sicherungen und Inventare kontrolliert behandelt wurden. Dazwischen ändern Patches, Konfiguration, Eigentümer und Workloadbedarf den Zustand. Wer nur „erstellen“ und „löschen“ betrachtet, verliert genau an diesen Übergängen die Nachvollziehbarkeit. ``text Image bauen → prüfen → freigeben → instanziieren → individualisieren → betreiben → ändern → erneuern → stilllegen → Nachweise schließen `` Jede Phase besitzt einen Eingang, eine Entscheidung und einen Ausgang. Eine freigegebene Vorlage ist Eingang der Bereitstellung. Eindeutige Gastidentität und bestandene Dienstprüfung sind ihr Ausgang. Eine Stilllegungsfreigabe ist Eingang des Decommissionings; ein aktualisiertes Inventar und nach Aufbewahrungsregel behandelte Datenträger sind sein Ausgang. Ein erfolgreicher Plattformjob allein beweist keinen fachlich vollständigen Übergang. Ordne deshalb zu jeder VM mindestens Quellenversion, Erstellungszeit, Workloadzweck, technischen und fachlichen Eigentümer, Umgebung, Schutzklasse, Ablauf- oder Reviewtermin sowie aktuellen Lebenszyklusstatus zu. Diese Metadaten dürfen nicht nur im Gast liegen: Ist er nicht mehr erreichbar, muss die Plattform weiterhin wissen, wem das Objekt gehört und welcher Prozess gilt.

Image, Vorlage und Instanz sind verschiedene Artefakte

Ein Basisimage enthält Betriebssystem und vorbereitete Pakete. Eine Vorlage macht ein geprüftes Image mit Hardwareprofil, Metadaten und Freigabestatus für die Provisionierung auswählbar. Eine Instanz erhält daraus eigene Ressourcen und eine eigene Betriebsidentität. Plattformen verwenden die Begriffe unterschiedlich; der Prozess muss daher ausdrücklich benennen, welches Artefakt unveränderliche Quelle ist und welches Objekt ab jetzt individuell betrieben wird. Ein vollständiger Klon kopiert typischerweise den Datenträgerzustand. Ein Linked Clone kann zusätzlich von einem Basisdatenträger abhängig bleiben. Beides erzeugt nicht automatisch neue Hostnamen, Maschinenkennungen, Zertifikate, Agenten-IDs, SSH-Hostschlüssel, Domänenbeziehungen oder Anwendungsschlüssel. Ob und wie diese Werte erneuert werden, ist Aufgabe des Gast- und Onboardingprozesses. Eine Plattformmeldung „Clone completed“ bestätigt nur ihre eigene Kopieroperation. Behandle eine Vorlage nicht wie eine laufende Produktiv-VM. Sie enthält keine aktive Workloadidentität, empfängt keinen normalen Nutzverkehr und wird nicht spontan per Hand gepflegt. Änderungen fließen durch einen reproduzierbaren Build oder einen dokumentierten Wartungsprozess in eine neue Version. Die alte Version bleibt während eines definierten Übergangs nachvollziehbar, wird aber für neue Produktion gesperrt, sobald ihr Nachfolger freigegeben ist. Notiere auch die Datenträgerbeziehung. Eine Instanz, die noch auf eine Basisdisk verweist, kann nicht unabhängig archiviert oder verschoben werden, ohne diesen Pfad zu berücksichtigen. Der sichtbare VM-Eintrag ist nicht das gesamte Artefakt.

Eine Vorlage braucht Herkunft statt den Namen „golden“

„Golden Image“ ist keine technische Eigenschaft. Vertrauenswürdig wird eine Vorlage durch belegte Herkunft: definierte Betriebssystemquelle, Buildrezept, Paket- und Konfigurationsstand, Prüfergebnisse, Freigabe und unverwechselbare Version. Ein Name wie ubuntu-final-neu trägt keine dieser Aussagen. Eine Version wie web-linux-2026.09.1 wird erst durch den zugehörigen Manifest- und Testnachweis sinnvoll. Ein einfaches Manifest kann so aussehen: ``yaml image: web-linux-2026.09.1 base: ubuntu-24.04.3 build-revision: 7f13c2a security-baseline: linux-web-v4 validation: passed released-at: 2026-09-03T18:00:00Z ` Das Manifest ist kein Ersatz für signierte Artefakte oder Plattformkontrollen, macht aber die Lieferkette sichtbar. Der Build muss deterministisch genug sein, dass dieselbe Eingabe dieselben beabsichtigten Eigenschaften erzeugt. Geheimnisse, langlebige Tokens und produktive Registrierungen gehören nicht in die Quelle. Sie werden bei der Instanziierung über einen dafür vorgesehenen, kurzlebigen Kanal bereitgestellt. Vor der Freigabe prüfst du mindestens Bootfähigkeit, erwartete Geräte, Patchstand, Baseline, Gastintegration, Onboardingweg und Entfernung temporärer Buildartefakte. Führe diese Tests an einer Instanz aus, die aus dem fertigen Artefakt erzeugt wurde; eine erfolgreiche Prüfung des Builders beweist nicht, dass das exportierte Image korrekt startet. Die Freigabe bezeichnet genau einen Digest oder eine unveränderliche Version, nicht einen beweglichen Namen wie latest`.

Generalisieren entfernt Quellidentität – Individualisieren erzeugt Zielidentität

Vor dem Erfassen einer Vorlage müssen maschinen- oder umgebungsspezifische Daten entfernt beziehungsweise für die Ersterzeugung vorbereitet werden. Unter Windows dient Sysprep mit der Option /generalize dazu, systembezogene Daten aus einer Installation zu entfernen, bevor das Image erneut bereitgestellt wird. Unter Linux können Werkzeuge wie virt-sysprep maschinenspezifische Werte in einem abgeschalteten Gast bereinigen. Cloud-Images bereiten häufig cloud-init als kontrollierten First-Boot-Mechanismus vor. Die konkrete Operation hängt vom Betriebssystem und Supportvertrag ab. Generalisierung ist nicht dasselbe wie vollständige Anonymisierung. Anwendungsdaten, lokale Konten, Zertifikate, Agentenregistrierungen oder Shell-Historien können außerhalb der Standardoperation liegen. Erstelle deshalb eine explizite Liste aller Identitäten der Workloadklasse. Prüfe nach dem Build sowohl, was entfernt wurde, als auch, was absichtlich im Image verbleibt. Die neue Instanz erhält Zielidentität erst im Onboarding: Hostname, Netzkonfiguration, Maschinenkennung, Hostschlüssel, Monitoring- und Backupregistrierung, Workload-Credentials sowie Inventarbezug. Der Ablauf sollte wiederholbar und bei Fehlern abbrechbar sein. Eine halb individualisierte VM darf nicht ins produktive Netz gelangen, weil dort Namens-, Zertifikats- oder Agentenkollisionen entstehen können. Nutze für den ersten Boot daher ein isoliertes Bereitstellungsnetz oder blockiere Produktionsverkehr bis zum bestandenen Gate. Erst wenn jede erwartete Identität eindeutig und jede verbotene Quellidentität abwesend ist, wechselt die VM vom Provisionierungs- in den Betriebsstatus.

Der erste Boot ist eine Transaktion mit Abbruchgrenze

First-Boot-Automatisierung verbindet Image und Umgebung. Sie bezieht Metadaten, setzt Identität, konfiguriert Netz und Zeit, registriert Agenten, holt kurzlebige Geheimnisse und meldet den Abschluss. Diese Schritte haben Seiteneffekte außerhalb der VM. Wiederholt ein fehlgeschlagener Lauf unkontrolliert Registrierungen oder Schlüsselanforderungen, entstehen Doppelobjekte und schwer widerrufbare Zugänge. Definiere daher Zustände wie provisioning, identity-ready, service-ready und admitted. Jeder Schritt muss erkennen, ob sein Ziel bereits korrekt erreicht ist, oder sicher abbrechen. cloud-init verwendet beispielsweise Instanzdaten und eine Instanzkennung, um den ersten von späteren Boots zu unterscheiden. Wird eine Kennung versehentlich wiederverwendet oder zurückgesetzt, kann sich Initialisierungsverhalten ändern. Das ist ein Teil des Identitätsvertrags, kein unsichtbares Implementierungsdetail. Ein Freigabegate prüft von innen und außen: Erwarteter Hostname und Maschinenbezug im Gast, eindeutige Agentenregistrierung in Monitoring und Backup, richtige DNS- und IP-Zuordnung, gültiger Zeitpfad, gewünschter Patchstand sowie Dienstfunktion über den vorgesehenen Netzweg. Bei einem Fehler bleibt die VM isoliert. Das Runbook widerruft bereits erzeugte kurzlebige Credentials und entfernt unvollständige Registrierungen, bevor ein neuer Versuch beginnt. Automatisches Retry ist nur sicher, wenn jeder Seiteneffekt eine Idempotenz- oder Kompensationsregel besitzt. Andernfalls entscheidet ein Operator anhand der erhaltenen Evidenz, ob fortgesetzt, bereinigt oder die Instanz verworfen wird.

Freigeben, befördern und sperren statt Vorlagen zu überschreiben

Eine neue Imageversion wandert durch getrennte Stufen: Build, technische Prüfung, Sicherheitsprüfung, workloadnahe Pilotierung und Produktionsfreigabe. Befördert wird dasselbe unveränderliche Artefakt. Wenn zwischen Test und Produktion erneut gebaut wird, wurde ein anderes Artefakt freigegeben als das getestete. Die Umgebung ergänzt Konfiguration und Geheimnisse bei der Instanziierung, verändert aber nicht heimlich die Imagequelle. Halte pro Version fest, welche Vorgängerversion sie ersetzt, welche Workloadklassen sie unterstützt und ab wann sie für neue Instanzen verpflichtend ist. Ein kritischer Betriebssystempatch ist erst dann im Lebenszyklus geschlossen, wenn auch die aktive Vorlage erneuert wurde. Sonst entstehen neue VMs weiterhin verwundbar und reintroduzieren die bekannte Abweichung. Laufende Instanzen und Vorlagen haben daher verbundene, aber getrennte Patchnachweise. Die alte Vorlage wird nicht sofort gelöscht. Zuerst sperrst du sie für neue Produktion, beobachtest den Nachfolger und hältst einen zeitlich begrenzten Rückweg. Rollback bedeutet nicht automatisch, eine verwundbare Version dauerhaft wieder zu öffnen. Bei einem kritischen Sicherheitsproblem kann stattdessen ein korrigierter Folgebuild erforderlich sein. Ein beweglicher Katalogalias darf auf eine freigegebene Version zeigen, doch die erzeugte VM speichert zusätzlich die konkrete Quellversion. Nur so kannst du später beantworten, welche Instanzen von einem fehlerhaften Build betroffen sind und ob ein Rückruf vollständig war.

Drift ist entweder verwaltet oder eine unklare zweite Quelle

Nach der Bereitstellung verändert sich eine VM durch Patches, Konfigurationsmanagement und erlaubte Workloaddaten. Nicht jede Abweichung von der Vorlage ist falsch. Falsch ist eine Abweichung, deren Autorität und Lebensdauer unbekannt sind. Ein manueller Notfallfix kann nötig sein, muss aber entweder in den gewünschten Zustand zurückgeführt oder mit Ablaufdatum als Ausnahme geführt werden. Trenne Imageeigenschaften von Laufzeiteigenschaften. Betriebssystemgrundpakete, Baseline und Agentengrundausstattung können aus dem Image stammen. Umgebungsspezifische Adressen, Secrets und Workloadkonfiguration kommen aus deklarierter Automatisierung. Veränderliche Anwendungsdaten gehören in ihren eigenen Schutz- und Recoveryvertrag. Wenn dieselbe Einstellung gleichzeitig im Image, im Konfigurationsmanagement und per Hand gepflegt wird, gewinnt beim nächsten Lauf möglicherweise eine andere Quelle. Bei Diagnose sicherst du zuerst Iststand und Autoritäten. Vergleiche Quellversion, letzte deklarierte Änderung, aktuellen Wert und offene Ausnahme. Rebuild ist eine mögliche Korrektur, aber nicht reflexartig: Er darf nur erfolgen, wenn Workloaddaten, Identität und Wiederanlaufpfad außerhalb der ersetzbaren Instanz geschützt sind. Ein regelmäßiger Driftbericht priorisiert sicherheits- und betriebsrelevante Abweichungen. Er löscht nicht automatisch unbekannte Werte. Eine überraschende lokale Konfiguration kann ein unerlaubter Fix sein – oder der einzige noch nicht dokumentierte Teil eines benötigten Dienstes. Erst Eigentümer und Quelle klären, dann kontrolliert konvergieren.

Klone und Snapshots übernehmen unterschiedliche Lebenszykluslast

Ein Klon erzeugt eine weitere Instanz oder Datenträgerbeziehung; ein Snapshot hält einen plattformspezifischen Zustand eines vorhandenen Objekts fest. Keines von beiden ist automatisch eine neue Vorlage, eine unabhängige Sicherung oder ein vollständiger Recoveryvertrag. Der Lebenszyklus muss erfassen, wem das neue Objekt gehört, wovon es technisch abhängt und wann es wieder entfernt wird. Bei Linked Clones oder differenzierenden Datenträgern bleibt die Basis Teil des Lesepfads. Eine scheinbar eigenständige Test-VM kann deshalb verhindern, dass eine alte Vorlage oder Basisdisk entfernt wird. Bei Snapshots wachsen je nach Plattform neue Änderungsdaten außerhalb des Basispunkts; lange oder unbekannte Ketten erschweren Kapazitäts- und Löschentscheidungen. Die tiefe Storagewirkung folgt später. Für den Lebenszyklus genügt die Regel: Jeder Klon und Snapshot erhält Zweck, Owner, Quellbezug, Ablauf und geprüften Rückweg. Verwende einen Snapshot nicht, um eine ungeprüfte Produktions-VM nachträglich zur dauerhaften Vorlage zu erklären. Laufzeitidentitäten, Daten und Drift bleiben darin enthalten. Soll ein nützlicher Fix in künftige Instanzen eingehen, übernimm ihn in das Buildrezept, erzeuge eine neue unveränderliche Version und durchlaufe das Freigabegate. Vor dem Entfernen einer Vorlage listest du abhängige Klone und Snapshots. Vor dem Entfernen einer Instanz klärst du, ob ihr Snapshot noch für ein offenes Change- oder Recoveryfenster benötigt wird. So wird eine temporäre Kopie nicht zum unbemerkten dauerhaften Asset und eine Aufräumaktion trennt keine noch aktive Datenträgerkette.

Eigentümer, Zweck und Ablauf gehören zur VM

VM-Sprawl entsteht selten durch eine einzelne große Entscheidung. Testsysteme bleiben nach Projekten aktiv, Besitzer wechseln Rollen, Ablaufdaten werden verlängert, ohne dass Bedarf und Schutzklasse erneut geprüft werden. Jede VM verbraucht dennoch Compute, Storage, Lizenzen, Backupzeit, Monitoringaufmerksamkeit und Angriffsfläche. Ein niedriger Speicherpreis macht ungeklärte Identität nicht kostenlos. Erfasse bei der Bereitstellung einen fachlichen Owner für Zweck und Aufbewahrung sowie einen technischen Owner für Betrieb und Reaktion. Ein Reviewtermin ist kein automatisches Löschdatum. Er löst eine Entscheidung aus: verlängern mit bestätigtem Zweck, übertragen an neue Eigentümer oder kontrolliert stilllegen. Bleibt die Bestätigung aus, wechselt die VM zunächst in einen Quarantäne- oder Stilllegungskandidatenstatus nach definierter Eskalation. Metadaten müssen validiert werden. Ein freies Textfeld mit einer ausgeschiedenen Person ist kein wirksames Eigentumsmodell. Nutze erreichbare Gruppen oder Rollen, prüfe Zuständigkeit regelmäßig und protokolliere Übertragungen. Kurzlebige Umgebungen können zusätzlich eine technische maximale Laufzeit erhalten, solange der Ablauf mit Daten- und Incidentanforderungen vereinbar ist. Verknüpfe Kosten- oder Kapazitätsberichte mit diesen Eigentumsdaten. Ziel ist nicht, möglichst viel zu löschen, sondern Entscheidungen an die Personen zu bringen, die Nutzen und Risiko beurteilen können. So wird Stilllegung zu einem erwarteten Lebenszykluspfad statt zu einer hektischen Aufräumaktion bei Kapazitätsdruck.

Stilllegung beendet Dienst, Daten und abhängige Objekte getrennt

Das Entfernen des VM-Eintrags beendet nicht automatisch den gesamten Lebenszyklus. DNS-Namen, IP-Reservierungen, Zertifikate, Servicekonten, Monitoring, Backupjobs, Snapshots, Datenträger, Katalogeinträge und Automatisierungszuordnungen können unabhängig weiterbestehen. Umgekehrt kann vorschnelles Löschen eines Datenträgers Aufbewahrungs- oder Wiederherstellungsanforderungen verletzen. Der sichere Ablauf beginnt mit fachlicher Freigabe, Verbraucher- und Abhängigkeitsprüfung. Danach legst du Aufbewahrung, Recoveryziel und Beweis fest. Entziehe produktiven Traffic kontrolliert und beobachte, ob unbekannte Abnehmer reagieren. Stoppe Zeitpläne und neue Schreibvorgänge, sichere benötigte Daten und teste den vereinbarten Wiederherstellungsweg. Erst dann entfernst du VM und abhängige Ressourcen in einer dokumentierten Reihenfolge. Bei Libvirt sind Domaindefinition und Storage getrennte Objekte. virsh undefine entfernt die persistente Definition; welche zugehörigen Speicher- oder Firmwareobjekte ebenfalls behandelt werden, hängt von Optionen und Konfiguration ab. Verwende deshalb kein generisches „VM gelöscht“ als Abschlussbeweis. Inventarisiere Ressourcen vorher und bestätige ihren Endzustand einzeln. NIST SP 800-88 beschreibt Medienbereinigung anhand von Informationsschutz und Wiederverwendungsziel. Ob ein virtuelles Volume logisch gelöscht, kryptografisch bereinigt oder physisch anders behandelt wird, hängt vom darunterliegenden Storage und der Datenklasse ab. Diese Entscheidung gehört dem Daten- und Plattformprozess gemeinsam. Am Ende schließt ein Bericht Eigentümer, Zeitpunkt, Aufbewahrung, entfernte Identitäten, behandelte Daten und verbliebene Ausnahmen.

Arbeitsbeispiel: eine fehlerhafte Vorlage zurückrufen