Eine P2V-Migration kopiert einen physischen Server in eine virtuelle Maschine. Das klingt nach einem Werkzeuglauf und ist eine Betriebsänderung: andere Treiber, andere Hardwarekennung, manchmal eine Lizenz, die am alten Mainboard hing, und die Gefahr, dass beide Kopien gleichzeitig im Netz stehen. Solange der physische Server nicht bewusst aus und die VM nicht bewusst die einzige Kopie ist, gibt es zwei Warenwirtschaften. Die Checkliste existiert, damit dieser Moment nicht am Freitagnachmittag nebenbei passiert.

Welche Altlasten die neue VM sofort wieder auswerfen

OEM-Lizenzen von Windows sind an die Hardware gebunden und ziehen nicht selbstverständlich mit. Manche Branchensoftware bindet sich an eine MAC-Adresse, einen Dongle oder eine Motherboard-ID. USB-Dongles brauchen eine durchgereichte Schnittstelle, die am Host noch existiert und nicht „irgendwie mit virtualisiert“ wird. Sonderkarten für Maschinen oder ISDN, die niemand mehr im Inventar hatte, lassen sich nicht in die VM stecken. Diese Punkte stoppen die Umstellung ehrlicher vor dem Kopieren als nach dem ersten Boot.

Nach dem Kopieren bleiben Geistergeräte: alte Netzwerkkarten, die im Geräte-Manager unsichtbar noch eine IP halten, Speichercontroller, die den Start verzögern, und Dienste, die auf einen COM-Port warten. Die VM bootet, die Anwendung wirkt langsam oder blind. Gleichzeitig darf der alte Server nicht „nur zum Vergleich“ im selben Netz bleiben. Doppelte Namen, doppelte IP und zwei Datenbanken, die beide Buchungen annehmen, sind der teuerste Ausgang einer sonst gelungenen Kopie.

Inventur, Probeboot und ein hartes Ausschalten des alten Geräts

  1. Inventur. Dongles, Sonderkarten, OEM-Hinweise, feste MAC-Adressen und Dienste auf lokalen COM- oder USB-Ports werden vor dem Kopieren gefunden. Was nicht mitkann, bleibt physisch oder wird ersetzt.
  2. Reinigen. Temporäre Daten und nicht mehr genutzte Anteile werden gelöscht, solange das Original noch das Original ist. Die Konvertierung kopiert sonst Ballast.
  3. Probe. Der erste Start der VM erfolgt ohne Verbindung zum Produktionsnetz. Geisteradapter fliegen heraus, die Anwendung wird vom Herstellerweg her gestartet, nicht nur „Windows ist oben“.
  4. Schnitt. Der physische Server verliert das Netz, bevor die VM ihre produktive IP bekommt. Es gibt keinen Tag, an dem beide antworten.
  5. Abnahme. Die Fachabteilung bucht einen echten Vorgang, danach greift ein Backup der VM. Erst dann endet die Frist, in der das Altgerät noch startfähig ist.

Der Rückweg ist der noch nicht veränderte physische Server, ausgeschaltet und beschriftet, nicht eine zweite laufende Kopie. Wir halten ihn für eine vereinbarte Frist betriebsbereit, aber ohne Kabel ins Produktionsnetz. Erst wenn die Fachabteilung einen echten Vorgang in der VM gebucht und eine Sicherung der VM gegriffen hat, wird das Altgerät zum Reserveteil oder zur Entsorgung freigegeben. Vorher ist P2V ein Versuch.

Woran Projekte in der Praxis scheitern

  • Beide Kopien gleichzeitig ins Netz lassen, „nur um zu vergleichen“.
  • Einen USB-Dongle im Schrank vergessen und die VM für defekt halten.
  • OEM-Windows umziehen und die Aktivierung dem Zufall überlassen.
  • Den alten Server sofort löschen, bevor ein Vorgang und ein Backup in der VM gelungen sind.

Beispiel aus dem Betriebsalltag

Ein Lohnbüro in Mödling wollte den Anwendungsserver am Wochenende konvertieren. Auf dem Blech steckte ein USB-Dongle, die Windows-Lizenz war OEM, und eine zweite Netzwerkkarte führte nur noch zu einem alten Drucker. Wir haben den Dongle am neuen Host durchgereicht, die Lizenzfrage vor dem Kopieren mit dem vorhandenen Lizenznachweis geklärt und die Drucker-NIC nicht mitgenommen. Der Probeboot lief isoliert, Geisteradapter wurden entfernt, und ein echter Abrechnungsvorgang wurde am Dienstag in der VM geprüft, während das Altgerät ohne Netzwerkkabel im Rack blieb. Erst nach dem Backup der VM wurde das Kabel des alten Servers als erledigt markiert. Ein paralleles Einschalten wäre zwei Datenbestände gewesen.

Kurze Entscheidungshilfe

  • Sind Dongles, Sonderkarten und Lizenzbindung vor dem Kopieren geklärt?
  • Startet die VM einmal isoliert, bevor sie die produktive Adresse erhält?
  • Ist sichergestellt, dass der physische Server in dem Moment kein Kabel mehr hat?
  • Gibt es ein Backup der VM, bevor das Altgerät freigegeben wird?

Wenn die Umstellung von physisch auf virtuell bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. Test- und Notfall-VMs Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.