Best Practices: Physisch zu virtuell (P2V) Migration

Folgen Sie diesen Best Practices in Bezug auf P2V-Migration (physische zu virtuell), konvertieren Sie physische Computer erfolgreich in eine VM.

Virtuelle Umgebungen machen sich in den Data Centern berechtigterweise immer weiter breit. Die meisten Data-Center-Manager und System-Administratoren werden irgendwann mit der Situation konfrontiert, physische Systeme in virtuelle Umgebungen migrieren zu müssen. In diesem Tipp finden Sie einige Best Practices zu P2V, wie sich eine Migration auch erfolgreich und ohne Zwischenfälle umsetzen lässt. Der erste Schritt ist, die richtigen Tools für eine P2V-Migration zu finden, und die Systeme zu identifizieren, die migriert werden sollen. Ist das geschafft, können Sie einen Plan machen, wie Sie die Migration aus der Perspektive eines Anwenders oder eines verbundenen Systems durchführen.

Vorbereitungen

Die Vorbereitung für die Migration kann im Grunde genommen länger dauern als der eigentliche Migrationsvorgang selbst. Ein Plan lohnt sich aber auf jeden Fall, gerade wenn Systeme migriert werden sollen, die sich nur schwer wieder auf den physischen Originalstand zurückbringen ließen. Nachfolgend finden Sie einige Planungsaufgaben zur Vorbereitung, um die PV2-Konvertierung so reibungslos wie umzusetzen:

· Bestimmen Sie mögliche Systeme für eine Virtualisierung. Es gibt in Ihrer Umgebung viele Faktoren, mit denen sich entsprechende Parameter herauskristallisieren lassen. Sie finden weitere Informationen in diesem TechTarget-Tipp (Englisch). Bereinigen Sie die Dateisysteme. Wenn Sie unnötig Dateien und Daten auf dem System vorgehalten haben und es soll migriert werden, verschieben oder löschen Sie die diese. Die Konvertierungs-Tools migrieren die gesamten Inhalte der Festplatten in die virtuelle Maschine. Damit können Sie sicherstellen, dass an dieser Stelle kein Platz verschwendet wird.

· Kündigen Sie vor dem Beginn eine realistische Ausfallzeit an. Führen Sie eine umfangreiche P2V-Migration durch, müssen Sie eine gewisse Downtime in Kauf nehmen und diese auch rechtfertigen, um die Migration erfolgreich durchführen zu können. In einer idealen Situation würde die Downtime nur den Zeitraum in Anspruch nehmen, um die DNS-Einträge zu ändern und die migrierten Systeme auf dem alten physischen Host herunterzufahren und die neuen virtuellen Maschinen zu starten.

· Bestimmen Sie vorab die Ressourcen-Aufteilung (Provisioning). Das ist die wohl wichtigste Entscheidung innerhalb des P2V-Prozesses. Es wäre eine Verschwendung an teuerer Host-Hardware, wenn Sie von Anfang an zu wenige System-Ressourcen bereitstellen, aber zu viele Ressourcen einem Gast-Betriebssystem einräumen, das dann doch nicht genutzt würde.

· Überprüfen Sie Storage und Netzwerk lieber doppelt. Storage und Netzwerk sind in der Regel die größten Hürden in einer virtualisierten Umgebung. Stellen Sie also sicher, richtige Verbindungen und ausreichendes Storage zu haben, damit Sie den gesamten Bestand an virtuellen Maschinen virtualisieren können.

· Versichern Sie sich, dass Sie von allen Anbietern ausreichend Support bekommen. Gewisse Software- und System-Hersteller unterstützen keine virtualisierten Umgebungen. Führen Sie diesen Schritt nicht durch, könnte das zu einer unangenehmen Situation für Ihr Unternehmen werden.

Nomenklatur der Systeme

Viele Firmen verfolgen die Strategie, alle virtuellen Maschinen mit einer entsprechenden Nomenklatur zu versehen. Zumindest der Server- oder System-Administrator weiß dann, dass es sich bei den jeweiligen Systemen und eine virtuelle Maschine handelt. Während des P2V-Prozesses kommen Sie an einen interessanten Scheideweg. Vielleicht möchten Sie einen Standard für die Server-Namen einführen, dass es sich um eine virtuelle Maschine handelt.

Sollte es im Unternehmen eine Nomenklatur für virtuelle Rechner geben, müssen Sie sich während der P2V-Migration entscheiden, wie Sie diese anwenden. Die einfachste Wahl ist natürlich, das System während der Konvertierung überhaupt nicht umzubenennen. Verwenden Sie den exakt gleichen Namen, ist der Übergang für die Anwender und die relevanten Systeme oder Verbindungen transparent. Das setzt allerdings voraus, dass alle Verbindungen zum System aufrecht erhalten bleiben. Die Migration ist in diesem Fall sehr einfach. Allerdings sollten Sie sich überlegen, ob sich der zusätzliche Aufwand nicht doch lohnt, eine neue Nomenklatur einzuführen.

Überlegungen hinsichtlich der Lizenzen

Im Eifer des Gefechts in Sachen Virtualisierung kann es schon vorkommen, dass Sie plötzlich mehr Instanzen an Betriebssystemen haben als zu Beginn des Projekts. Stellen Sie daher sicher, dass das Original-System nach der Migration auf eine virtuelle Maschine in die digitale Rente geschickt und nicht anderweitig wieder eingesetzt wird. Nach der Migration wollen Sie nicht feststellen, dass die physische Maschine mit der gleichen Betriebssystem-Installation für andere Zwecke verwendet wird. Damit Sie die Lizenz-Grenzen beim Migrations-Prozess nicht überschreiten, limitieren Sie die TCP/IP-Adressen, die für die virtuellen Maschinen zur Verfügung stehen. Diese Maßnahme löst allerdings das Problem mit doppelten Lizenzen nicht vollständig. Dieser Bereich ist allerdings sehr wichtig und Sie sollten die Situation mit Argus-Augen beobachten, damit Sie mit Ihren Lizenzen konform bleiben.

VMware: Alt zu Neu

Migrieren Sie innerhalb einer VMware-Umgebung, gibt es einiges bei einer V2V-Migration (virtuell zu virtuell) zu beachten. Migrieren Sie virtuelle Maschinen von einem älteren auf einen neuere Host, sollten Sie die nachfolgenden Optionen in Betracht ziehen.

· VMware Converter Tool: Es führt einen Snapshot durch, wenn die Konvertierung beginnt und schreibt ein Image auf das System des neuen Hosts.

· VMware Clone Process: Der VMware-Klonvorgang kopiert die existierende virtuelle Maschine auf die neue Host-Umgebung. Je nach Wunsch lassen sich auch grundlegende Optionen während der Migration konfigurieren, ähnlich dem SysPrep-Tool für Windows-Systeme.

· VMware Migrate Process: Hier haben Sie die Möglichkeit, die virtuelle Maschine von einem Host auf einen neuen zu verschieben. Die VM bleibt dabei nicht auf dem Original-Host.

Den Volume Shadow Copy Service verstehen

Falls Sie ein Tool erwenden, das Windows-Systeme während des Betriebs konvertieren kann, nutzt dieses wahrscheinlich den Volume Shadow Copy Service für eine Migration. In diesem Fall wird das Image beim Start der Konvertierung vom System aufgenommen. Sobald der Migrationsvorgang abgeschlossen ist, würden Sie das Original-System herunterfahren. Behalten Sie allerdings im Hinterkopf, dass die Zeit zwischen dem Start der Konvertierung und dem Herunterfahren des ursprünglichen Systems auf der physischen Maschine aber weitergelaufen ist. Die neu erschaffene virtuelle Maschine ist dann nicht mehr aktuell. Das ist vor allen Dingen für Domänen-Controller sehr wichtig. Wir behandeln Domänen-Controller in einem separaten Abschnitt weiter unten in diesem Tipp. Das gilt auch für sämtliche Systeme, die transitiven Daten oder Logging zu tun haben.

Migrations-Tests vor der eigentlichen Inbetriebnahme

Das Konzept einer P2V- oder V2V-Migration beeinflusst die Funktionalität des entsprechenden Systems in der Regel nicht. Sie sollten allerdings jeden Migrations-Kandidaten nach der Migration auf Herz und Nieren testen und dem System erst danach wieder die ursprüngliche Rolle zuweisen. Nachfolgend finden Sie einige Tipps, wie Sie migrierte virtuelle Maschinen überprüfen können:

· Entfernen Sie bei gerade umgewandelten virtuellen Maschinen alle unnötige Hardware aus dem Inventar. Das gilt im Speziellen bei der Migration von einem physischen Host. Möglicherweise haben Sie hier USB-Schnittstellen, Disketten-Laufwerke und möglicherweise sogar Soundkarten. Unter Umständen brauchen Sie das auf der Host-VM nicht.

· Starten Sie das System auf dem Virtualisierungs-Host ohne verbundene Netzwerkkarten in der Konfiguration. Das ist ein sanftes Deaktivieren. Bei VMware ESX können Sie das erreichen, indem Sie die Option „connect at power-on“ deaktivieren.

· Sofern möglich, stoppen Sie ihre wichtige Applikation, falls diese in einer Offline-Umgebung nicht die erwünschten Resultate oder Leistung bringt.

· Starten Sie die virtuelle Maschine nach der Migration mehrere Male neu. Damit stellen Sie sicher, dass alle Logs sauber sind und es auch nach mehreren Neustarts keine Komplikationen gibt.

· Während die Netzwerkkarte sanft deaktiviert ist, stellen Sie sicher, dass die Netzwerk-Konfiguration für seinen neuen Standort in der virtualisierten Umgebung korrekt ist. Eine Migration entfernt möglicherweise die bisherigen Schnittstellen aus dem Hardware-Inventar, womit auch die Netzwerk-Konfiguration nicht mehr verfügbar wäre.

· Werfen Sie auch einen Blick auf die erweiterten Netzwerk-Konfigurationen wie zum Beispiel die Reihenfolge der DNS-Server und DNS-Suffix. Das gilt auch für alle weiteren Netzwerk-Konfigurations-Parameter, die Sie eventuell an die neue Umgebung anpassen müssen. Während dieser Zeit können Sie auch Änderungen außerhalb des migrierten Systems vornehmen, sollte das notwendig sein. Auch hier wären DNS-Einträge ein gängiges Beispiel.

Nachdem Sie die eben genannten Tests durchgeführt haben, aktivieren Sie die Netzwerkkarte an der virtuellen Maschine wieder, wenn sich die Gast-VM im ausgeschalteten Zustand befindet. Erledigen Sie die hier erwähnten Tests, sparen Sie sich jede Menge Zeit. Sobald Sie die virtuelle Maschine nun anschalten, sind alle Feineinstellungen bereits vorgenommen und Sie können das System produktiv nutzen.

Windows-Domänen-Controller brauchen eine Sonderbehandlung

Migrieren Sie einen Domänen-Controller von einem physischen Computer in eine virtuelle Instanz, müssen Sie anders an die Sache herangehen. Das hängt damit zusammen, wie die virtuelle Maschine in der neuen virtualisierten Umgebung platziert wird. Viele System-Administratoren wollen die Downtime des Domänen-Controllers so gering wie möglich halten. Somit tendieren Sie möglicherweise zu einem Tool, dass für eine Online-Benutzung optimiert ist. Das Problem an dieser Stelle ist, dass so lange der Domänen-Controller in Betrieb ist, wachsen die internen Berechnungen der Domäne mit jeder Sekunde. Sollte das P2V-Migrations-Tool die Konvertierung im laufenden Betrieb vornehmen, könnte das die lokale Active-Directory-Datenbank beschädigen, sobald die virtuelle Maschine hochgefahren wird. Möglicherweise sind auch andere Domänen-Controller und Computer-Konten betroffen.

In diesem Tipp zeige ich Ihnen zwei komfortable Wege, wie Sie einen Domänen-Controller konvertieren können. Die sicherste Methode ist, eine neue Installation in einer virtuellen Umgebung durchzuführen. Danach integrieren Sie dieses System als neuen Domänen-Controller in die Domäne. Sobald dieser Schritt erledigt ist, stellen Sie sicher, dass der globale Katalog und andere Rollen entsprechend übertragen werden. Sobald das neue System online ist, können Sie das physische System absetzen und aus der Domäne entfernen.

Die andere Methode ist genauso sicher, bringt aber eine gewisse Downtime mit sich. Haben Sie einen VMware-Host mit einer älteren Version von ESX, können Sie die virtuelle Maschine klonen. Dieser Klon-Vorgang kopiert das Image auf den neuen Host in einem ausgeschalteten Zustand. Es ist sehr wichtig, dass die virtuelle Maschine deaktiviert ist, da in diesem Fall die Synchronisation mit dem Rest der Domäne nicht verloren geht. Diese Methode ist aber nur dann empfehlenswert, wenn sich zusätzliche Domänen-Controller im Einsatz befinden, während Sie das erste System migrieren.

Die richtige Migrations-Strategie wählen

Je nach den entsprechenden Umständen für die Migration physischer auf virtuelle Maschinen, müssen Sie sich für die richtige Strategie entscheiden. Nur so ist die bestmögliche Uptime gewährleistet und die Lizenz-Konformität garantiert. Wählen Sie deswegen den Weg des geringsten Widerstandes. Versuchen Sie die Migration für verbundene Systeme und Anwender so transparent wie möglich zu machen. Verwenden Sie nicht einfach Konvertierungs-Tools wie VMware Converter oder PlateSpin PowerConvert, um die physischen Maschinen so schnell wie möglich zu virtualisieren. Halten Sie sich an die hier aufgezeigten Tipps, damit eine Migration so erfolgreich wie möglich ist.

Über den Autor:

Rick Vanover ist ein MCSA-zertifizierter System-Administrator und arbeitet für Belron US. Während seiner Karriere war er auch schon für Siemens und Dematic tätig. Bei letzterer Firma hatte er es mit komplexen Logistik-Systemen zu tun. Rick arbeitet seit mehr als zehn Jahren in der IT und hat seit mehr als sieben Jahren mit Virtualisierungs-Technologien zu tun. Artikel zu seinen Spezial-Gebieten veröffentlicht er seit über sechs Jahren.

Artikel wurde zuletzt im August 2014 aktualisiert

Erfahren Sie mehr über Server- und Desktop-Virtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close