Warum eine P2V-Migration nicht immer eine gute Idee ist

Wer in der Servervirtualisierung eine virtuelle Maschine (VM) einrichten will, steht vor der Auswahl zwischen zwei grundsätzlichen Methoden:

1. Man kann die VM völlig neu definieren und dann das Betriebssystem und die Anwendungen installieren. Falls es bereits eine bestehende Umgebung mit der betreffenden Applikation gibt, kann man deren Daten migrieren.
2. Alternativ kann man auch das bereits bestehende Serversystem in eine VM konvertieren. Handelt es sich dabei um einen vorhandenen physischen Server, so nennt man das oft eine “P2V-Migration” (Physical-to-virtual).

P2V-Migrationen sind seit vielen Jahren eine durchaus bewährte Methode. Und doch eignet diese sich längst nicht immer für die Produktion. Warum nicht?

Vorhandene Mängel bleiben erhalten

In der Praxis sind bestehende Serversysteme oft “gewachsen”. Sie sind vielleicht schon jahrelang gelaufen, und die Installation hat einige Änderungen erfahren. Bisweilen hat es Fehler im System gegeben, die bearbeitet, aber nicht vollständig behoben wurden. Das Einrichten und Entfernen von Software oder Treibern hat seine Spuren hinterlassen. Und häufig ist auch die Applikation, um die es eigentlich geht, nicht ganz sauber eingerichtet.

Eine P2V-Migration übernimmt diese Konfiguration im Wesentlichen unverändert. Plakativ gesagt: Ein schlecht konfigurierter SQL-Server ist auch nach der P2V-Migration ein schlecht konfigurierter SQL-Server.

Online-Migration ist nicht online

Die meisten P2V-Werkzeuge bieten heute an, die Konvertierung in eine VM im laufenden Betrieb vorzunehmen. Das ist praktisch, denn so kann man den Vorgang im normalen Tagesgeschäft durchführen und muss keine Abend- oder Wochenendarbeit einplanen. Doch das hat seine Tücken.

Damit diese Konvertierung gelingt, führen die P2V-Tools bei Windows-Maschinen meist einen VSS-Snapshot aus, damit die Daten der Applikation konsistent sind. In diesem Fall arbeiten die Anwender mit dem laufenden System weiter, während die P2V-Konvertierung auf Basis des Snapshots erfolgt. Schaltet man nun aber nach dem Abschluss der Konvertierung auf die VM um, so befindet diese sich im Zustand des Snapshots – also vereinfacht gesagt in der Vergangenheit. Die Änderungen, die die Anwender während des Vorgangs am Originalsystem vorgenommen haben, sind damit verloren.

Damit solche Datenverluste nicht auftreten, ist dringend zu empfehlen, die Applikationen des Systems während der P2V-Migration abzuschalten und zu deaktivieren. Damit allerdings findet die Konvertierung eben nicht mehr “online” statt: Zwar ist das Betriebssystem erreichbar, die Anwendung aber nicht.

Das Originalsystem bleibt nicht original

Eine virtuelle Maschine unterscheidet sich zwangsläufig von einem physischen Server. So ist ein großer Teil der eingesetzten Treiber in beiden Welten unterschiedlich. Viele “bessere” P2V-Tools berücksichtigen dies und bereiten zu Beginn der P2V-Migration das Quellsystem auf die Konvertierung vor, indem sie bestimmte Treiber und Komponenten abschalten, entfernen oder manipulieren.

Sollte sich während oder nach der P2V-Konvertierung aber zeigen, dass das Zielsystem nicht wie gewünscht läuft, ist der Rückweg hierdurch vielleicht eingeschränkt. Da das Originalsystem verändert wurde, kann es hier zu Fehlern beim “Fail-back” kommen, wenn die P2V-Vorbereitungen nicht oder nicht vollständig widerrufen werden. Trotz des grundsätzlich vorhandenen Rollback-Weges bleibt also ein deutliches Risiko.

Das Zielsystem ist (noch) nicht optimal

Wie gerade erwähnt, muss ein P2V-Vorgang in größerem Stil Treiber austauschen und dafür sorgen, dass die erzeugte VM in der Virtualisierungsumgebung ordentlich läuft. Einfachere Werkzeuge verlassen sich dabei im Wesentlichen auf die Plug-and-Play-Mechanismen von Windows. Sie machen im Prinzip nicht viel mehr, als die Daten des Originalservers in eine virtuelle Festplatte zu kopieren. Startet man die so erzeugte VM zum ersten Mal, so erkennt Windows die neue (virtuelle) “Hardware” und bindet diese mit den nötigen Basis-Treibern ein.

Hier ist zwingend Nacharbeit erforderlich, wenn die erzeugte VM ordentlich laufen soll. Viele Administratoren übersehen diesen wichtigen Schritt allerdings. Er besteht aus (mindestens) zwei Teilschritten:

1. Installieren und Konfigurieren der Virtualisierungskomponenten: Dazu zählen etwa die VMware-Tools bzw. die Hyper-V-Integrationskomponenten.
2. Deinstallieren alter Hardware-Treiber: Nach der P2V-Migration verbleiben meistens die Treiber für die Hardware, aus der der physische Server bestand, in der Systemkonfiguration. Dies kann zu Instabilitäten oder Performance-Nachteilen führen.

Für den zweiten Teilschritt empfiehlt es sich, noch vor der Inbetriebnahme der konvertierten VM Alttreiber und nicht mehr benötigte Software (z.B. die RAID-Verwaltungssoftware) zu deinstallieren. Das geschieht zunächst über deren Deinstallationsprogramme. Danach sollte man im Geräte-Manager die Ansicht nicht mehr vorhandener Geräte aktivieren und die “Altlasten” entfernen. Hierbei ist natürlich Sorgfalt nötig – und damit einiges an Zeit.

Nicht jedes Werkzeug ist geeignet

Es gibt eine große Zahl an Werkzeugen, die man für eine P2V-Migration einsetzen kann oder könnte. Längst nicht jedes davon ist aber auch für die konkrete Aufgabe geeignet.

So nutzen viele Windows-Administratoren etwa gern die kostenlose Software “Disk2VHD” von Sysinternals. Diese ist aber gar kein P2V-Tool, sondern nur ein Konvertierungsprogramm, das Daten in virtuelle Festplatten übertragen kann. Dass eine P2V-Migration damit oft (zumindest grundsätzlich) gelingt, ist den oben skizzierten Plug-and-Play-Fähigkeiten von Windows zu verdanken. In jedem Fall ist hier aber Nacharbeit erforderlich. Und oft scheitert solch eine Konvertierung auch – die Foren sind voll von Fragen, die sich auf Probleme mit Disk2VHD beziehen.

Doch auch spezialisierte Software kann scheitern. Gerade beim Konvertieren älterer physischer Server kommt es oft vor, dass die P2V-Software an der RAID-Konfiguration des Originalsystems scheitert oder mit anderen speziellen Treibern nicht umgehen kann. Wer wirklich alte Betriebssysteme per P2V übertragen möchte (und dazu zählt heute auch Windows Server 2003), stellt vielleicht sogar fest, dass die Tools damit gar nicht zusammenarbeiten.

Vorsicht bei der Handhabung

In der Praxis sehen wir darüber hinaus noch zahlreiche andere Fehler, die im Zusammenhang mit P2V-Migrationen auftreten können. Hier eine Auswahl.

• Multifunktionsserver bleiben erhalten: Ein häufiger Grund für P2V-Migrationen sind “komplexe Installationen”, die die Admins aus Bequemlichkeit nicht neu bauen wollen. Die konvertierten Systeme behalten diese Komplexität und ihre Nachteile (z.B. Kombination von Applikationen, die nicht gut miteinander laufen).
• Quellsystem bleibt nicht offline: Ein per P2V erzeugtes System übernimmt die Identität des Originalservers. Das Quellsystem darf hinterher also nie wieder online gehen. Immer wieder schalten Admins aber (versehentlich) das Altsystem wieder ein – die Folgen reichen von Netzwerkfehlern bis hin zu inkonsistenten Datenbeständen, die sich nicht mehr abgleichen lassen.
• Plattenplatz verschwendet: Ein einfacher P2V-Vorgang übernimmt die Konfiguration des Quellsystems quasi “1:1” und erzeugt virtuelle Festplatten genauso, wie die physischen Festplatten konfiguriert waren. Hat man also im Altsystem eine riesige Festplatte, die fast leer ist, belegt die VM auf dem teuren SAN mit ihrer virtuellen Festplatte denselben unnötigen Platz. So lastet man sein kostbares SAN schnell mit “lauter leerem Platz” aus.
• Unsinnige Partitionierung: Auf physischen Servern arbeiten viele Administratoren auch heute noch mit (überholten) Partitionierungsschemata. So ist eine Festplatte in mehrere Partitionen oder Volumes aufgeteilt. Eine simple P2V-Konvertierung übernimmt dies und erzeugt eine einzelne virtuelle Festplatte mit mehreren Partitionen. Damit nimmt man sich die Flexibilität, die virtuelle Platten bieten – will man die Partitionsgrößen ändern, so ist dies oft ein sehr aufwändiger Prozess, oder es ist gleich ganz unmöglich. Als Faustregel sollten virtuelle Festplatten niemals mehr als eine Partition aufweisen – benötigt man mehrere Volumes, so legt man mehrere virtuelle Disks an.

Vorteile des “Neuanfangs”

Neben diesen immanenten Problemen und Risiken der P2V-Migrationen gibt es auch eine ganze Reihe von direkten Vorteilen, wenn man eine VM neu erzeugt und eine Daten- bzw. Anwendungsmigration vornimmt. Auch hier nur ein paar ausgewählte Beispiele.

• Betriebssystem nach aktuellem Standard: Eine neue VM kann man “sauber” installieren und auf einen aktuellen Patchlevel, eine günstige Plattengröße und vieles mehr achten.
• Höheres Sicherheitsniveau: Ungünstige Konfigurationen des Quellsystems kann man weglassen, etwa Remote-Zugangssoftware, die man gar nicht mehr benötigt, oder Administrator-Konten, die nicht mehr verwendet werden.
• Aktuelle Versionen: Ein Vorteil, der oft unterschätzt wird – eine Anwendungsmigration bietet die Chance, im selben Zug auf eine neue Version der betreffenden Applikation umzusteigen.
• Weniger Downtime: Je nach der einzusetzenden Applikation kann eine Anwendungsmigration sogar mit weniger Downtime auskommen als eine P2V-Konvertierung. Im Fall von Exchange etwa kann man die Mailboxen von einem Altserver im laufenden Betrieb auf einen neuen Server übertragen, ohne dass die Anwender eine Unterbrechung bemerken. Eine P2V-Migration hingegen wird nicht ohne Downtime auskommen.

Fazit: Kann man machen, ist aber nur selten besser

Es spricht nicht grundsätzlich etwas gegen P2V-Migrationen. Das Vorgehen ist im Prinzip erprobt und bewährt. Trotzdem ist es in vielen Fällen – oder nach meiner Ansicht sogar in den meisten Fällen – weniger gut geeignet als der Neuaufbau einer VM mit einer gut geplanten Anwendungsmigration.

Falls man sich doch für eine P2V-Konvertierung entscheidet, sollte man auf jeden Fall die nötige Sorgfalt walten lassen. Die Aufgabe muss gut vorbereitet sein, und nach dem Abschluss der “technischen” Konvertierung muss zwingend eine Bereinigung und Anpassung des Zielsystems erfolgen. Eine “Fire-and-Forget”-Lösung ist P2V beileibe nicht.