Neben den Konvertierungstools von Nutanix oder Microsoft, die mit "Nutanix-Move" und "Microsoft Azure Site Recovery" Workloads zwischen Plattformen und Clouds migrieren, ist VMware mit seinem "VMware vCenter Converter Standalone" (VCC) [1] nun auch wieder im Rennen. Der VMware Converter Standalone 3 von 2008 gehörte noch zur VMware-Infrastructure-3-Familie und mit ihm war es sogar noch möglich, eine P2V-Boot-CD zu erstellen, mit der sich ein ausgeschalteter physischer Computer in eine VM konvertieren ließ.

Mit dem "VMware vCenter Converter Standalone" von 2018 war dann aber erst einmal Schluss mit der Weiterentwicklung und der Support endete 2019. Schließlich entfernte VMware den Converter Anfang 2022 von seinen Downloadseiten mit dem Hinweis auf "Sicherheitsrisiken in der Software". Ab diesem Zeitpunkt mussten sich die VCC-Nutzer mit Werkzeugen anderer Anbieter behelfen, wenn sie etwa physische Server in virtuelle Maschinen umwandeln oder bereits vorhandene VMs auf eine abweichende Plattform verlegen wollten. Doch Ende 2022 stand dann überraschend wieder ein Converter von VMware bereit.

Das Tool hilft dabei, VMs von einer anderen Plattform in eine vSphere-Umgebung zu importieren. Bei einem derartigen Vorhaben sprechen wir von "Virtual to Virtual" (V2V). Sollen physische Win-dows- oder Linux-Maschinen zu VMs werden, steht Ihnen der Converter "Physical to Virtual" (P2V) zur Verfügung. Darüber hinaus gibt es noch die Konvertierungsarten "Virtual to Physical" (V2P), "Physical to Physical" (P2P), "Physical to Cloud" (P2C), "Cloud to Cloud" (C2C) oder auch "Physical to Image" (P2I). Bild 1 liefert einen Überblick, was das Tool im Hinblick auf In- und Output leistet.

Und dann stellt sich natürlich auch noch die Frage nach dem Wohin beziehungsweise auf welcher Zielplattform die VMs landen sollen: Soll das Ziel eine vSphere- oder eine VMware-Typ-2 Hypervisor-Umgebung sein, ein gehosteter Hypervisor, VMware Workstation beziehungsweise Player oder VMware Fusion für macOS – all diese Szenarien bildet VCC ab.

Der Converter steht nur für Windows zur Verfügung und Sie können ihn in einer virtuellen Maschine oder auf einem physischen Server betreiben. Er setzt sich aus drei Modulen zusammen: Server, Agent und Client. Der Agent kommt nur bei der Konvertierung von Windows-Quellsystemen zum Einsatz, nicht jedoch bei Linux-Maschinen. Im Zuge des Konvertierungsprozesses wird der Agent automatisch installiert, was Sie jedoch in einem Dialogfenster auch steuern können. Entscheiden Sie sich dagegen, lässt er sich natürlich auch manuell deinstallieren. Der Server kümmert sich um den Im- und Export von Workloads und besteht wiederum aus Server- und Worker-Diensten. Er kommuniziert als zentrale Komponente mit dem Client, dem Agenten oder, wenn es sich nicht um eine Windows-Quellmaschine handelt, via SSH mit dem zu konvertierenden Zielsystem. Der Client stellt unter anderem die Benutzeroberfläche zur Verwaltung und Konfiguration zur Verfügung und erlaubt Ihnen somit die direkte Interaktion mit dem Converter-Server-Dienst.

Die Installation und Inbetriebnahme des Converters ist recht schnell erledigt. Es gibt grundsätzlich zwei Installationsarten: die lokale und die Client-Server-Installation. Bei der Client-Server-Variante spielen Sie die Server-Komponente des Converters auf einem Windows-Hostsystem ein, auf das Sie mit den Clients, die dann auf anderen Windows-Systemen installiert werden, remote zugreifen und Konvertierungsjobs von dort aus auf dem Server ablaufen lassen. Bei der lokalen Installationsvariante landen alle Dienste gemeinsam auf einem Windows-System. Ein wichtiger Hinweis an dieser Stelle: Der Converter-Server benötigt Admin-Rechte des Systems, um einwandfrei arbeiten zu können.

Eine weitere Art der Installation ist die automatisierte Installation über die Windows-CLI. Wer sich für diese Methode interessiert, findet unter [2] die entsprechenden Kommandos mit den zugehörigen Optionen für das Erstellen einer Batch-Datei.

Befindet sich der Converter bereits auf Ihrem System und Sie möchten ihn wieder deinstallieren, dann rufen Sie die Installationsdatei, die Sie heruntergeladen haben, auf, führen "Remove" aus und folgen den Anweisungen des Wizards. Sollte der Converter auf ihrem System beschädigt sein und Sie möchten den automatischen Reparaturvorgang starten, gehen Sie nach der gleichen Methode wie bei einer Deinstallation vor. Im Wizard finden Sie im gleichen Dialogfenster den Auswahlpunkt "Repair".

Der Converter erlaubt die Konvertierungen von Quellsystemen mit BIOS als auch UEFI. Allerdings ist keine Umwandlung der Firmware-Schnittstelle möglich, was bedeutet, dass Quellmaschinen mit BIOS als Interface dies auch nach der Konvertierung weiterhin nutzen. BIOS in UEFI umwandeln ist also nicht machbar. Um vor einer Konvertierung genau in Erfahrung zu bringen, welche Schnittstelle in Verbindung mit welchem OS von VM-ware aktuell supportet wird, hilft [3]. Hier stellt VMware auch ein entsprechendes PDF bereit, doch wir empfehlen, möglichst immer online nachzuschauen, denn nicht selten hinkt das PDF der offiziellen Doku hinterher. Eine weitere wichtige Quelle für Ihren Konvertierungscheck ist die "Product Interoperability Matrix" [4] von VMware. Diese informiert Sie darüber, ob die Zielplattform überhaupt noch unterstützt wird.

Nicht alle Betriebssysteme sind von VCC zur Konvertierung freigegeben. Pauschal lässt sich sagen, dass Windows-Server- und Workstation-Betriebssysteme sowie die verbreitetsten Linux-Varianten wie Ubuntu, CentOS und Red Hat Enterprise Linux, kurz RHEL, als Quellsysteme unterstützt werden. Eine aktuelle Liste liefert [5] . Dort gibt es Tabellen, in denen Sie die genauen Versionsbezeichnungen der Betriebssysteme, die sich konvertieren lassen, nachschlagen können.

Auch sehr wichtig zu wissen ist, dass VCC 6.3.x keine Merkmale unterstützt, die in den virtuellen Hardwareversionen über 11 liegen. Das bedeutet, dass selbst wenn Ihre VM eine Hardwareversion größer als 11 aufweist, die Features nach der Konvertierung nicht zur Verfügung stehen werden. Die aktuellen Hardware-Versionen sind 19 und bei ESXi 8 die 20.

Konvertieren Sie eine Quellmaschine mit mehreren Disks oder Volumes, können Sie die Standardeinstellung von "1" erhöhen. Die maximale Anzahl liegt hier bei zwölf gleichzeitigen Verbindungen. Was die parallelen Job-Tasks angeht, lässt sich ebenfalls ein Höchstwert von zwölf hinterlegen. Dies erfolgt allerdings nicht innerhalb eines Konvertierungsjobs, sondern im Converter selbst unter dem Menüpunkt "Administration".

Bei der Konvertierung eines eingeschalteten Windows-Rechners installiert der Converter zunächst einen Agenten auf der Quellmaschine. Dann erstellt er einen Snapshot des Quell-Volumes. Im nächsten Schritt erzeugt VCC eine VM in der Zielumgebung. Anschließend kopiert der Agent alle Daten aus dem Snapshot der Quellmaschine auf das Volume der virtuellen Zielmaschine. Als Nächstes spielt VCC die für den Start des Betriebssystems erforderlichen Treiber ein und personalisiert die Zielmaschine, indem er unter anderem eine IP-Adressen-Anpassung durchführt. Anschließend wird der Agent, sofern Sie das vor der Erstellung des Jobs bestätigt haben, wieder deinstalliert.

Ist die Quelle eine Linux-Maschine, funktioniert alles ein wenig anders. Bei Linux-Konvertierungen landet kein Agent auf der Quellmaschine, vielmehr verbindet sich VCC via SSH mit dieser und ruft alle für den Migrationsprozess benötigten Systemkonfigurationen ab. Dann legt VCC eine virtuelle Hilfsmaschine mittels Linux-ISO in der Zielumgebung an. Diese Maschine wird anschließend eingeschaltet, startet vom Linux-Image und stellt dann eine Verbindung zur Quellmaschine her. Via SSH kopiert VCC nun die Daten von der Quellmaschine zur virtuellen Hilfsmaschine im Ziel. Danach erhält die Hilfsmaschine die Konfiguration der Quellmaschine und das Tool fährt sie herunter.

Je nachdem, wie sich eine Quellmaschine zusammensetzt und wie die Zielmaschine nach der Konvertierung aussehen soll, bietet der Converter Ihnen verschiedene Konvertierungsoptionen. VCC verwendet unterschiedliche Methoden für das Hot-Cloning von Volumes. Hot-Cloning erfolgt, wenn die Maschine eingeschaltet ist.

Welche Methode das Tool anwendet, hängt davon ab, welches Dateisystem in der Quellmaschine vorhanden ist und ob Sie im Zuge der Konvertierung eine Größenveränderung vornehmen. Beispielsweise nutzt der Converter das Volume-based-Cloning auf File-Level, wenn in einer Windows-Quellmaschine als Filesystem NTFS arbeitet und Sie das Volume im Zuge der Migration verkleinern möchten, um im Ziel Speicherplatz einzusparen. Vergrößern Sie das Ziel-Volume hingegen oder belassen es in seiner ursprünglichen Größe, dann verwendet der Converter Volume-based-Cloning auf Block-Level, was deutlich schneller ist. Berücksichtigen Sie dabei, dass VCC bei Windows-Systemen dynamische Festplatten im Ziel in Basic-Disks umwandelt. Eine Änderung der Dateisystemformate erfolgt bei den gängigsten Typen nicht.

Ein weiteres Verfahren ist das sogenannte Disk-based-Cloning (festplattenbasiertes Klonen). Diese Methode wird angewendet, wenn eine virtuelle Maschine ausgeschaltet ist, und ist auch als Cold-Cloning bekannt. Das Verfahren erstellt exakte Kopien im Hinblick auf Größe, Partitionierung und Art der Disks und ist performanter als das Volume-based-Cloning.

Zu guter Letzt können Sie Linked-Clone nutzen. Dies ist eine separate Instanz, die quasi die Diskressourcen einer VM mitbenutzt. Ein Beispiel: Ein Linked-Clone (Child) liest die Daten von der Disk einer VM (Parent) und benötigt somit auch keine eigene Kopie dieser Disk. Die Erzeugung eines Linked-Clones ist also extrem performant. Wenn der Converter dieses Verfahren im Zuge der Konvertierung nutzen soll, muss die Quellmaschine ausgeschaltet sein und Sie wählen in den Optionen des Converter-Jobs unter "Data copy type" wie zu erwarten "Linked Clone" aus.

Selbstverständlich ist es auch möglich, während des Konvertierungsvorgangs einzelne Disks, die in der Zielmaschine nicht notwendig sind, einfach wegzulassen. Aber leider ist mit VCC nicht alles konvertierbar, so zum Beispiel RDM-Disks, RAID-Verbunde oder GPT/MBR-Hybrid-Konstrukte. Hinsichtlich der Unterstützung von "Thin" und "Thick" in einer vSphere-Infrastruktur beziehungsweise "Pre-allocated", "Not pre-allocated", "Split pre-allocated" und "Split not pre-allocated", wenn das Ziel eine gehostete Hypervisor-Umgebung ist, sollten Sie einen Blick in die Doku unter [6] und [7] werfen. Hier gibt es eine ganze Reihe für die Migrationsplanung wichtige Eckdaten und Grenzwerte.

Der Converter verwendet während einer Konvertierung unterschiedliche TCP/IP- und UDP-Ports. Welche Ports wann, wofür und wie zum Einsatz kommen, hängt unter anderem auch davon ab, mit welchem Betriebssystem Sie es beim Importieren zu tun haben und ob es sich um einen ein- oder ausgeschalteten Workload handelt.

Es kommt in der Praxis wirklich sehr häufig vor, dass eine Konvertierung schief geht, weil einer der benötigten Kommunikationsports nicht wie erforderlich zur Verfügung steht. Bevor Sie also aufwendig nach Problemen am Quell- oder Zielsystem suchen, prüfen Sie zunächst, ob das Problem nicht an der Verbindung zwischen den Komponenten liegt. Ein Hinweis: Sie müssen nicht unbedingt dieIP-Adresse der beteiligten Systeme verwenden, sondern können auch auf die entsprechenden FQDNs mit den zugehörigen Portnummern zurückgreifen.

Grundsätzlich ist bezüglich der benötigten Ports bei P2V-Konvertierungen zwischen Windows und Linux zu unterscheiden. Bei einer Migration einer virtuellen Maschine (V2V) müssen Sie hingegen davon abweichende Ports konfigurieren. Eine Übersicht dazu finden Sie in der Tabelle. Alle Details zu den Ports liefert [8].

Wie Bild 2 zeigt, stehen Ihnen bei Konvertierungsjobs unterschiedliche Optionen zur Verfügung. Bei der Anpassung der Ziel-VM sind dies "Data to Copy", "Devices", "Networks", "Services", "Advanced Options" und "Throttling". Nehmen Sie hier eine Änderung vor, kennzeichnet VCC diese durch eine blaue Raute vor dem jeweiligen Unterpunkt. So können Sie überprüfen, ob Sie beabsichtigt oder versehentlich eine Änderung vorgenommen haben.

Mit "Data to copy" passen Sie das Disk-Layout an. Möchten Sie die Ziel-Disk nach Ihren Wünschen umgestalten, bietet der Converter hier unter "Advanced" mit den erweiterten Möglichkeiten im "Destination Layout" die entsprechenden Optionen. Hier ändern Sie den Typ oder die Größe der vorhandenen Disks und definieren die Blockgröße für jede einzelne Partition. VCC erlaubt hier auch, der Ziel-VM neue Disks hinzuzufügen, auf die Sie dann Partitionen verschieben, die sich bisher auf einer der vorhandenen Disks befanden.

Unter "Devices" nehmen Sie Einstellungen bezüglich vRAM, vCPU und vDisk-Controller vor. Im Dialogbereich "Memory" unterstützt der Converter Sie mit Empfehlungen hinsichtlich der vRAM-Ausstattung. In CPU-Settings für Ihre Ziel-VM ist es möglich, die vCPUs und vCores granular zu konfigurieren. Als dritte Einstellmöglichkeit können Sie den Disk-Controller für Ihre Zielmaschine anpassen.

Mit "Networks" definieren Sie, ob die VM beim Einschalten in das Netzwerk genommen werden soll oder nicht. Sie legen den vSwitch fest, an den die Ziel-VM angeschlossen wird, und zu guter Letzt passen Sie vNIC oder Netzwerkcontroller nach Ihren Wünschen an.

Mit den Services-Einstellungen sind Sie in der Lage, die unterschiedlichsten Service-Parameter für die Zielmaschine einzustellen. Möchten Sie beispielsweise einen Dienst im Zuge des Imports von "automatisch" auf "manuell" umstellen, so erfolgt dies hier. Sie müssen also die Services nicht unbedingt in der eingeschalteten Quellmaschine herunterfahren, um einen Dienst auf der Zielmaschine zu deaktivieren. Derartiges können Sie also in den Konvertierungs-Task aufnehmen. Voraussetzung ist allerdings, dass der von Ihnen benötigte Service hier aufgeführt ist. Die "Advanced Options" definieren beispielsweise, ob die VM nach der Fertigstellung angeschaltet werden oder ob sie die VMware Tools erhalten soll. Derartige Optionen bieten sich Ihnen hier in einer Art Multiple Choice.

Unter "Throttling" können Sie, falls Sie einmal einen Konvertierungsprozess zu einem Zeitpunkt durchführen müssen, in dem die Ressourcen knapp sind, Quotas zum Einsatz bringen. Dabei legen Sie die maximale Netzwerkbandbreite und CPU-Ressourcen für die Konvertierung fest. Hier hinterlegen Sie die Netzwerkbandbreiten in MBit/s, die CPU-Nutzung regeln Sie allerdings via "Medium", "Light" oder "None".

Im Anschluss an eine erfolgreiche Konvertierung sollten Sie den neuen Workload nicht sofort starten, denn das kann zu unerwünschten Effekten führen. Je nachdem, in welche Umgebung Sie die neue VM gebracht haben, sollten Sie jetzt die Einstellungen überprüfen und gegebenenfalls anpassen. Der erste Schritt ist immer die virtuelle Hardware. Haben Sie beispielsweise eine physische Maschine konvertiert, sind möglicherweise noch virtuelle Hardwarekomponenten vorhanden, die Sie nicht länger benötigen oder für eine VM gar keinen Sinn mehr ergeben.

Gehen Sie sicherheitshalber alle Punkte in den Eigenschaften der VM durch: Schauen Sie sich die Netzwerkeinstellungen an, etwa die IP-Adresse der VM. Denken Sie daran, dass möglicherweise noch das Original läuft. Am besten trennen Sie die VM für diese Überprüfung vom virtuellen Switch. Sehen Sie auch nach, ob VCC die VMware Tools installiert hat. Ist Ihnen dies durchgegangen, können Sie dies auch nachträglich erledigen. Der Converter erlaubt Ihnen nämlich, auch ausgeschaltete VMs via "Configure machine" zu konfigurieren, und Sie spielen die VMware Tools hier im Nachgang ein.

Checken Sie nach dem Einschalten, ob das Betriebssystem Fehler meldet, alle Serverdienste starten und ob die Anwendungen ordnungsgemäß funktionieren. Falls Sie diverse Services vor der Konvertierung im Betriebssystem oder Applikationen aus Sicherheitsgründen gestoppt haben, ist jetzt der Zeitpunkt gekommen, alles wieder zu starten. Wenn Sie damit fertig und mit dem Resultat zufrieden sind, fahren Sie das Original, also die Quellmaschine, herunter, schließen die VM wieder an den vSwitch an und starten sie anschließend.

Wir haben den neuen Converter zum Testen auf einem bereits etwas betagterem Lab-PC aus der Lenovo-M-Series unter Windows 10 (19043.2364) lokal installiert. Für eine Testumgebung passt das gerade noch, haben Sie allerdings den produktiven und möglicherweise auch noch automatisierten Einsatz im Auge, sollten Sie den Converter natürlich auch mit ausreichenden Ressourcen versorgen.

In unserer Testumgebung ist VCC, da auf dem Lab-PC installiert, jetzt auch die Managementstation für die Physical-to-Virtual-Konvertierung. Wir wandeln also den physischen Lab-PC in einen virtuellen um. Als Ziel für die VM steht eine vSphere-7-Umgebung bereit. Das Ganze benötigt nur wenige Schritte, bis ein neuer Converter-Job in der UI zu sehen ist.

Wir starten also den Converter als Administrator und klicken dann auf "Convert machine", um den Konvertierungsassistenten zu starten. In der folgenden Dialogbox wählen wir als "Source Type", dass die zu konvertierende Maschine eingeschaltet ist und dass wir vorhaben "This local machine" zu konvertieren. Mit einem Klick auf "View Source Details" checken wir, ob VCC die Daten der Maschine ausgelesen hat. Hätten wir den Converter nicht als Administrator gestartet, würden wir das spätestens jetzt anhand einer Fehlermeldung merken. Ein Klick auf "Next" öffnet nächste Dialogfenster, wo wir mittels einer Listbox das Ziel der VM auswählen. Jetzt geben wir noch die IP-Adresse oder FQDN von vCenter oder ESXi nebst Anmeldedaten ein und klicken "Next". Der Converter scannt nun die Umgebung und zeigt VMs an, die bereits in der Umgebung existieren.

Weiter geht es erneut mit "Next" und im nächsten Dialog legen wir dann unter anderem den Data-Store fest, auf den der Converter den Lab-PC speichern soll. Im nächsten Dialogfenster lassen sich dann noch zusätzliche Einstellungen, wie etwa die Änderung der Hauptspeichermenge, die Anzahl der NICs oder das Einspielen der VMware-Tools, einrichten. Abschließend bekommen wir eine Übersicht der Einstellungen und mit einem Klick auf "Finish" erzeugen wir einen Job und führen ihn aus.

Der Lab-PC hat eine Plattengröße von rund 60 GByte und die vSphere-Umgebung ist netzwerkseitig mit 1 GBit/s angebunden. Die Konvertierung hat rund 20 Minuten gedauert. Bei Quellmaschinen, die große Datenmengen beinhalten, kann eine Konvertierung je nach Netzbandbreite jedoch deutlich länger dauern. Bitte sorgen Sie immer dafür, dass während der gesamten Konvertierung das Netzwerk so stabil und performant wie möglich zur Verfügung steht.

 VMware gibt Admins mit dem vCenter Converter Standalone wieder ein bewährtes und mächtiges Tool für Konvertierungen von physischen Serversystemen und Workloads zurück. Das Erscheinungsbild der aktuellen Version ist zwar nicht mehr hundertprozentig zeitgemäß und das User-Interface macht den Einsatz im modernen Rechenzentrum nicht leicht, aber der Funktionsumfang des Converters ist nach wie vor absolut bedarfsgerecht. Doch bei aller Kritik an der GUI, deren Entwicklung in Richtung HTML 5 gewiss wünschenswert ist, sollten wir nicht vergessen, dass das Tool kostenfrei verfügbar ist.