Neu in vSphere 7: Programmatische Instant-Clone-Gastsystemanpassung

Klone sind eine schnelle Bereitstellungstechnik für VMs, die insbesondere bei der Desktop-Virtualisierung zum Einsatz kommt. VMware-Nutzer können VMs aber auch Workstation und vSphere klonen. Allgemein handelt es sich beim Klonen um ein Verfahren zum schnellen Erstellen von Kopien virtueller Maschinen. VMware kennt im Kontext von vSphere, Horizon und Workstation drei verschiedene Klone-Technologien Full-Clone, Linked Clone und Instant Clone. Letztere haben in Version 6.7 eine neue Architektur erhalten und wurden seitdem stetig verbessert. In vSphere 7 spendiert VMware dem Instant-Clone-Verfahren eine API für die Anpassung der Netzwerkeinstellungen im Gastsystem, was programmatische Workflows zur Bereitstellung von Instant-Clone-VMs noch effizienter macht.

Wenn du zunächst einen fundierten Einstieg in vSphere benötigst, empfehle ich dir die Teilnahme am Kurs VMware vSphere: Install, Configure, Manage.

Unter Full Clone versteht VMware vollständige, unabhängige Kopien virtueller Maschinen, die vollständig von der ursprünglichen, bzw. übergeordneten VM getrennt ausgeführt werden. Trotzdem sind sie schneller bereitgestellt als reguläre VMs, weil die Gastsystem-Installation 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.

Unter einem Linked Clone (verknüpfter) Klon versteht VMware eine Momentaufnahme einer virtuellen Maschine, die fortlaufend virtuelle Festplatten mit der übergeordneten VM teilt. Das spart Festplatten-Speicherplatz und ermöglicht es mehreren VMs, den gleichen Stapel an Softwareinstallation zu verwenden. Die Technik beschleunigt das Erstellen eindeutiger virtueller Maschinen für einzelne Aufgaben und erlaubt die schnelle Weitergabe von VMs an Nutzer, die Zugriff auf dieselben virtuellen Festplatten benötigen (z. B. Support- und Entwicklerteams).

Instant Clones alt und neu

Instant Clones (sofortige Klone) sind Linked Clones sehr ähnlich. Sie teilen sich eine virtuelle Festplatte einer übergeordneten VM und verbrauchen damit weniger (Festplatten)Speicher als eine vollständige VM. Instant Clones tun das Gleiche aber auch mit Arbeitsspeicher. Dazu werden Instant Clones stets von einer laufenden VM erstellt. Damit funktionieren und verhalten sich Instanz Clones eher wie Container als wie VMs. Trotzdem sind Instant-Clones voll funktionsfähig und sehr schnell startklar, während bei herkömmlichen Klonen noch ein vollständiger Betriebssystemstart erforderlich ist, der samt ordnungsgemäßer Konfiguration einige Minuten dauern kann.

Instant Clone (VMware-intern auch als „VMFork“ bezeichnet) gibt es (z. B. in Horizon) eigentlich schon seit einigen Jahren. Die Funktion war auch schon Mal in vSphere 6.0 verfügbar, auch wenn das wesentliche Einsatzszenario eigentlich Horizon View mit seinen Just-in-Time-Desktops war und ist. Obwohl Instant Clone also schon immer Teil der vSphere-Kernplattform waren, standen öffentliche APIs 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 Gründe für VMware, die APIs (vor vSphere 6.7) nicht öffentlich verfügbar zu machen, waren zum Teil auf die ursprüngliche Instant Clone-Architektur zurückzuführen, die bestimmte Einschränkungen und Einschränkungen aufwies. VMware wollte aber wohl auch auf Nutzer-Feedback darüber warten, wie Kunden Instant Clone unter dem Gesichtspunkt der Automatisierung nutzen würden.

Die zaghafte Öffnung begann mit der Veröffentlichung eines „PowerCLI-Instant-Clone-Extension“-Flings, das ergänzend zu den privaten APIs eine weitere Abstraktionsebene bereitstellte. Darauf basierend veröffentlichte VMware dann zunächst das Fling  https://flings.vmware.com/vmfork-for-pyvmomi  „Instant Clone für pyvmomi“ (vSphere SDK für Python), mit dem Kunden programmgesteuert 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.

Ab vSphere 6.7

Für vSphere 6.7 sah sich das Instant Clone-Produkt-Team dann offenbar durch die Erkenntnisse aus Horizon View und dem Feedback von Kunden, welche die Flings verwendeten, veranlasst, hinter den Kulissen intensiv an der Vereinfachung der Instant Clone-Architektur und der Beseitigung von Einschränkungen zu arbeiten. Mit der Veröffentlichung von vSphere 6.7 steht die neu entwickelte Instant Clone-Funktion Kunden zur Verfügung und kann mithilfe einer nun öffentlichen vSphere-API verwendet werden. Diese erste Neuveröffentlichung von Instant Clone bietet die Grundlage für zukünftige Verbesserungen der Instant Clone-Technologie, wie sie nun z. B. in vSphere 7 eingeflossen sind. Das soll laut VMware aber nur ein Anfang sein.

Die neue Architektur

Der größte Hauptunterschied zu früheren Versionen von Instant Clone besteht darin, dass es keine enge Kopplung mehr zwischen SourceVM (Parent) und DestinationVM (Child) gibt, wodurch eine Reihe von Einschränkungen wegfallen, die Instant Clones vor 6.7 daran hindern, die wichtigsten vSphere-Funktionen wie vMotion, Cross vCenter  vMotion, Storage vMotion, DRS, HA usw. nutzen zu können. In der neuen Version von Instant Clone, die auch als “Parentless” Instant Clone bezeichnet wird, hängt die instanziierte VM nicht mehr von der SourceVM ab.

Der Instanz Clone ist nach der Instanziierung eine unabhängige VM, die aber auf dem exakten Ausführungsstatus der Quell-VM ausgeführt wird. Dies ermöglicht die schnelle Bereitstellung von VMs, die im Gegensatz zu herkömmlichen vollständigen Klonen sofort zum Gerbrauch verfügbar sind. Diese sofortige Bereitstellung wird dadurch ermöglicht, dass sowohl der Arbeitsspeicher- als auch der Festplattenstatus der SourceVM gemeinsam genutzt werden. Unter dem Gesichtspunkt des Speichers teilen sich alle Instant Clones dieselben physischen Speicherseiten wie ihre SourceVM. Dies gilt auch bei Nutzung von Transparenter Speicherfreigabe (TPS).

Unter Speichergesichtspunkten werden Delta-Festplatten für Festplatteneinsparungen genutzt, die sich ähnlich wie bei einem verknüpften Klon verhalten. Im Gegensatz zu einem verknüpften Klon, der eine Snapshot-basierte Delta-Festplatte verwendet, verwendet Instant Clone jedoch eine andere Technik. Diese erlaubt es nun auch, Instant Clones entweder aus einer laufenden oder einer eingefrorenen SourceVM zu erstellen. In der Vergangenheit musste man die SourceVM “einfrieren”, was bedeutete, dass sie im Rahmen des Workflows zur 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 und schelle Bereitschaft
• Instant Clone sind quasi sofort eingeschaltet und damit für Benutzer zum Herstellen einer Verbindung bereit
• Einsparungen bei der Speichernutzung
• Vereinfachte Bereitstellung und Patches für Administratoren

Instant Clone Workflow

Beim Erstellen eines neuen Instant Clone wird die SourceVM kurz „betäubt“ (stunned). Dabei wird für jede virtuelle Festplatte eine neue Delta-Festplatte erstellt, die auf die ursprüngliche SourceVM verweist. Dann wird ein Speicherprüfpunkt von der SourceVM erfasst und auf die Ziel-VM übertragen. Außerdem werden auch für die DestinationVM neue Delta-Festplatten erstellt, die aber ebenfalls auf die ursprüngliche SourceVM verweisen.

Nur unabhängige Klone lassen sich übrigens im vSphere-Client erstellen. Die GUI orchestriert den gesamten Workflow zum Erstellen eines neuen Klons mit einer neuen MAC-Adresse und einer eindeutigen Kennung für den Klon. Das Erstellen von Linked Clone und Instant Clones hingegen kann nur über die CLI erfolgen.

Auch wenn die sich mit dem Feature ergebenden Einsatzmöglichkeiten unbegrenzt erscheinen bedeutet die Nutzung, dass für jede Anpassung, einschließlich der grundlegenden Gast-Identitäts-Merkmale wie Hostname und Netzwerk, ein alternativer Workflow verwendet werden muss. Was die Anpassung auf Anwendungsebene betrifft müssen Kunden benutzerdefinierte Skripte erstellen und verwalten.

Neu in vSphere 7

VSphere 7 bringt nun eine neue Funktion „Guest Customization Engine für Instant Clone“ mit. Sie erlaubt die Unterstützung der nativen vSphere-Gastanpassung für Instant Clone in vSphere 7 für eine Reihe von Linux-Gastbetriebssystemen, 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, die man verwenden muss, um die neue Funktion zur Anpassung von Instant Clone-Gästen nutzen zu können. Der „GuestCustomizationManager2 ist eine neue vSphere 7.0-API, die die folgenden drei API-Methoden enthält:

• AbortCustomization_Task
• CustomizeGuest_Task
• StartGuestNetwork_Task

Details zur neuen API finden sich in der https://code.vmware.com/docs/11721/vmware-vsphere-web-services-sdk-programming-guide/GUID-E63E67E4-370C-4437-9EC6-444D17DC4E05.html vSphere-SDK-Dokumentation. System-Architekten können also nun die Netzwerkeinstellungen im Gastbetriebssystem mithilfe des vSphere Web Services SDK anpassen. Bei Instant Clones muss die Anpassung des Klons erfolgen, ohne das Gastbetriebssystem anzuhalten. Die Anpassung des Gastnetzwerks für eine laufende virtuelle Maschine umfasst 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 Skripten zur anwendungsabhängigen Anpassung