Neu in vSphere 7: Gastbetriebssystem von Instant Clones per Script anpassen

Linked Clone (verknüpfter) Klon nennt VMware eine Moment­aufnahme einer virtuellen Maschine, die fortlaufend virtuelle Festplatten mit der übergeordneten VM teilt. Das spart Speicherplatz und ermöglicht es mehreren VMs, den gleichen Stapel an Software-Installation zu verwenden.

Unter Full Clone versteht VMware vollständige Kopien virtueller Maschinen, die unabhängige von der ursprünglichen VM ausgeführt werden. Trotzdem sind sie schneller bereitgestellt als reguläre VMs, weil die Installation des Gast-OS- entfällt.

Da Full Clones virtuelle Festplatten nicht mit der ursprünglichen übergeordneten VM gemeinsam nutzen, haben sie im Allgemeinen eine bessere Leistung als Linked Clones. Allerdings dauert die Bereitstellung länger.

Im vSphere-Client lassen sich übrigens nur unabhängige Klone erstellen. Die GUI orchestriert den gesamten Workflow für das Klonen, darunter auch das Zuweisen einer neuen MAC-Adresse und einer eindeutigen Kennung. Linked Clones und Instant Clones erhält man hingegen kann nur über die CLI.

Öffnung von Instant Clones für Automatisierung

Instant Clones (sofortige Klone) sind Linked Clones sehr ähnlich. Sie teilen sich eine virtuelle Festplatte mit einer übergeordneten VM und verbrauchen damit weniger Plattenplatz als eine vollständige VM.

Instant Clones tun zusätzlich das Gleiche mit dem Arbeitsspeicher. Daher erzeugt man sie stets auf Basis einer laufenden VM. Damit funktionieren und verhalten sich Instant Clones eher wie Container als wie VMs.

Trotzdem sind Instant Clones voll funktionsfähig und sehr schnell startklar, während beim her­kömmlichen Klonen noch ein vollständiger Betriebs­systemstart erforderlich ist, der samt ordnungs­gemäßer Konfiguration einige Minuten dauern kann.

Instant Clones (VMware-intern auch als VMFork bezeichnet) gibt es zum Beispiel in Horizon schon seit einigen Jahren. Die Funktion war auch schon einmal in vSphere 6.0 verfügbar, auch wenn das wesentliche Einsatz­szenario eigentlich Horizon View mit seinen Just-in-Time-Desktops war und ist.

Öffentliche APIs standen jedoch vor vSphere 6.7 nicht für den externen Gebrauch zur Verfügung. Trotzdem waren viele Kunden an der Technologie interessiert, um auch andere Nicht-VDI-Anwendungsfälle wie Dev/Test, Continuous Integration / Continuous Development (CI / CD) oder sogar Container-Workloads in vSphere zu ermöglichen.

Die zaghafte Öffnung begann mit der Veröffentlichung des Flings PowerCLI-Instant-Clone-Extension, das ergänzend zu den privaten APIs eine weitere Abstraktions­ebene bereitstellte. Darauf basierend veröffentlichte VMware dann zunächst das Fling Instant Clone für pyvmomi (vSphere SDK für Python), mit dem Kunden programm­gesteuert auf die privaten APIs zugreifen konnten.

Beide Flings waren ein großer Erfolg und laut Wiliam Lam gab es sogar Kunden, welche die pyvmomi-Instant-Clone-Module in der Produktion verwendeten, um mehrere hundert Instant Clone-VMs pro Tag für ihre CI- / CD-Workloads bereitzustellen.

Seit vSphere 6.7 können Kunden die neu entwickelte Technik für Instant Clones inklusive eines nun öffentlichen vSphere-API verwenden. Dieses Update von Instant Clone bildet die Grundlage für zukünftige Verbesserungen dieser Technologie, wie sie nun in vSphere 7 eingeflossen sind.

Die neue Architektur für Instant Clones

Der Hauptunterschied zu früheren Versionen von Instant Clone besteht darin, dass es keine enge Kopplung mehr zwischen Source-VM (Parent) und Destination-VM (Child) gibt, wodurch einige Einschränkungen wegfallen.

Diese bestanden vor allem darin, dass Instant Clones vor 6.7 die wichtigsten vSphere-Funktionen wie vMotion, Cross vCenter vMotion, Storage vMotion, DRS oder HA nicht nutzen konnten. In der neuen Version, auch als Parentless Instant Clone bezeichnet, hängt die instanziierte VM dagegen nicht mehr von der Source-VM ab.

Der Instant Clone ist eine unabhängige VM, die aber auf dem exakten Status der Quell-VM ausgeführt wird. Dies ermöglicht die schnelle Provisionierung von VMs, die im Gegensatz zum her­kömmlichen vollständigen Klonen sofort einsatzbereit sind, weil der Instant Clone sowohl den Arbeits­speicher als auch der Festplattenstatus der Source-VM mitnutzt.

Alle Instant Clones teilen sich dieselben physischen Speicherseiten wie ihre Source-VM. Dies gilt auch beim Einsatz von Trans­parenter Speicherfreigabe (TPS).

Speichereinsparungen erzielt VMware durch Delta-Festplatten, die sich ähnlich wie bei einem verknüpften Klon verhalten. Anders als dieser verwendet Instant Clone jedoch keine Snapshot-basierte Delta-Festplatte, sondern eine andere Technik.

Diese erlaubt es nun auch, Instant Clones entweder aus einer laufenden oder einer eingefrorenen Source-VM zu erstellen. In der Vergangenheit musste man die Source-VM einfrieren, was bedeutete, dass sie während der Erstellung von Instant Clones nicht mehr verfügbar war.

Damit liegen die Vorteile von Instant Clonen auf der Hand:

• Deutlich kürzere Zeiten für die Bereitstellung
• Instant Clones sind praktisch sofort eingeschaltet und damit für Benutzer zum Herstellen einer Verbindung bereit
• Einsparungen bei der Speichernutzung
• Vereinfachte Wartung für Administratoren

Instant Clone Workflow

Beim Erstellen eines neuen Instant Clone wird die Source-VM kurz "betäubt" (stunned). Dabei wird für jede virtuelle Festplatte eine neue Delta-Festplatte angelegt, die auf die ursprüngliche Source-VM verweist.

Anschließend wird ein Speicher­prüfpunkt der Source-VM erfasst und auf die Ziel-VM übertragen. Außerdem entstehen dabei für die Destination-VM neue Delta-Festplatten, die aber ebenfalls auf die ursprüngliche Source-VM verweisen.

Auch wenn die Einsatz­möglichkeiten unbegrenzt erscheinen, bedeutete die Nutzung des Features bisher, dass für jede Anpassung, etwa des Hostname und des Netzwerks, ein alternativer Workflow erforderlich war.

Guest Customization Engine in vSphere 7

VSphere 7 bringt nun eine neue Funktion namens Guest Customization Engine für Instant Clone. Sie unterstützt die native vSphere-Gastanpassung für Instant Clone in vSphere 7 bei mehreren Linux-Gastbetriebs­systemen. Dazu zählen darunter RHEL und CentOS ab 7.4, RHEL 6.8, Ubuntu 16.04, SuSE 11 SP4 und SuSE 12 SP3.

Darüber hinaus gibt es eine Reihe neuer vSphere (SOAP)-APIs, um Instant Clone-Gäste anpassen zu können. Der Guest Customization Manager ist ein neues vSphere 7.0-API, die die folgenden drei Methoden enthält:

• AbortCustomization_Task
• CustomizeGuest_Task
• StartGuestNetwork_Task

Details dazu finden sich in der vSphere-SDK-Dokumentation.

System-Architekten können nun die Netzwerk­einstellungen im Gastbetriebs­system mithilfe des vSphere Web Services SDK anpassen. Dies umfasst für eine laufende virtuelle Maschine mehrere Schritte:

1. Installation der Gastanpassungs-Engine
2. Trennen von virtuellen Netzwerkkarten
3. Anpassen der Einstellungen des Gastnetzwerks
4. Virtuelle Netzwerkkarten erneut verbinden
5. Neustart des Gastnetzwerks
6. Wiederherstellung nach Gastanpassungsfehlern
7. Ausführen etwaiger Scripts zur anwendungsabhängigen Anpassung