Der schwere Teil beim Abschied von VMware ist, Windows auf Proxmox VE zum Booten zu bringen

VMware zu verlassen erwies sich als die leichte Entscheidung. Windows danach auf Proxmox VE zum Booten zu bringen war der Teil, der Nerven gekostet hat.

Das Lizenzchaos machte diesen Teil fast schon emotional. Sie sitzen in einem Meeting, starren auf eine Tabelle, und plötzlich geht die Rechnung einfach nicht mehr auf. Also tun Sie, was viele Infrastruktur-Teams zuletzt getan haben: Sie entscheiden sich für Proxmox, skizzieren einen Migrationsplan und reden sich ein, es sei im Grunde ein V2V-Problem mit einem anderen Logo auf der Oberfläche.

Diese Zuversicht hält genau bis zu dem Moment, in dem Ihre erste Windows-VM bootet und sofort mit dem Gesicht voran in einen Bluescreen kracht. Beim nächsten Versuch wieder, und beim übernächsten auch.

Was jetzt folgt, handelt von Annahmen, von VMware-trainierten Instinkten und von einer Handvoll Details, die die meisten Migrationsleitfäden höflich überspringen, weil sie unordentlich, unglamourös und bestens dazu geeignet sind, Ihr Wochenende zu sprengen. Proxmox ist dabei nicht "schlecht" und Windows nicht "furchtbar", auch wenn Windows sich diesen Ruf manchmal verdient.

Ihr mentales Modell aus der VMware-Zeit steht im Weg

Wenn Sie jahrelang im VMware-Land gelebt haben, ist Ihr Gehirn auf eine bestimmte Weise verdrahtet. Storage-Controller fühlen sich abstrahiert an, Migrationen fühlen sich transaktional an. Sie bewegen Bits, schalten ein, machen weiter. Proxmox spielt dieses Spiel nicht mit.

Unter der Haube ist es unverfroren Linux, KVM, und explizit darin, wie Hardware Gästen präsentiert wird. Das ist eine gute Sache. Es ist schnell, flexibel und ehrlich. Es bedeutet aber auch, dass Windows plötzlich sehr genau weiß, wovon es bootet, und es mag keine Überraschungen.

Linux-VMs zucken dabei kaum. Die meisten von unseren liefen beim ersten Versuch, beschwerten sich ein bisschen über Netzwerkschnittstellen und machten dann einfach weiter. Windows, besonders älteres Windows, reagiert eher so, als hätten Sie den Motor eines Autos ausgetauscht, während es auf der Autobahn fuhr.

Die erste Falle: Cluster-Networking, das fast funktioniert

Bevor wir überhaupt zu den Bluescreens kommen, gibt es einen Networking-Fehler, der in Postmortems immer wieder auftaucht.

Auf dem Papier fühlt sich eine gemeinsam genutzte 10-GbE-Verbindung großzügig an, mit reichlich Bandbreite und reichlich Spielraum. Warum also nicht Cluster-Traffic, Management und Migrationen für den ersten Umzug gemeinsam mitfahren lassen?

Weil Proxmox-Cluster auf Corosync laufen, und Corosync kümmert sich nicht um Bandbreite, sondern um Latenz. Und es mag es überhaupt nicht, wenn die Latenz plötzlich in die Höhe schnellt, weil Sie beschlossen haben, die Verbindung mit einer Multi-Terabyte-Migration zu sättigen.

Was als Nächstes passiert, sieht dramatisch aus, wenn Sie es nicht erwarten. Knoten verpassen Heartbeats, der Cluster geht davon aus, dass etwas nicht stimmt, Fencing greift ein, und Maschinen starten sich selbst neu, weil sie glauben, isoliert worden zu sein. Von außen sieht es aus, als würde Proxmox in Panik geraten. In Wirklichkeit tut es genau das, wofür es entworfen wurde.

Die Lösung ist nicht exotisch. Trennen Sie den Traffic physisch, oder legen Sie Migrationen zumindest auf ein eigenes VLAN mit echter Isolation. Sobald wir aufgehört haben, Daten über denselben Pfad wie den Heartbeat zu jagen, verschwanden die zufälligen Neustarts. Die Lektion daraus: "Empfohlen" in der Dokumentation heißt bei Clustern nicht "optional".

Dann kam Windows und die BSOD-Schleife

Das ist der Teil, über den alle nur flüstern. Sie importieren eine Windows-VM, klicken auf Start, der Boot-Bildschirm blitzt auf, und dann steht da INACCESSIBLE_BOOT_DEVICE.

Der Grund ist schmerzhaft einfach, sobald man ihn sieht. VMware präsentiert Storage über Controller, von denen Windows bereits weiß, wie es davon bootet. Proxmox nicht. Es erwartet, dass Sie für die Performance VirtIO nutzen, und Windows wird sich rundheraus weigern, von einem Controller zu booten, den es nicht als boot-kritisch markiert hat.

Der Haken ist, dass es nicht genügt, die Treiber zu installieren. Sie können den VirtIO-Installer den ganzen Tag laufen lassen, aber wenn Windows nie eine VirtIO-Disk sieht, während es läuft, markiert es den Treiber oft nicht dafür, während der Boot-Phase geladen zu werden. Nach der Migration wacht Windows auf, sucht nach dem alten Controller, findet ihn nicht und gibt auf. Und da ist der Bluescreen.

Der dumme Trick, der tatsächlich funktioniert

Die verlässlichste Lösung entpuppte sich als unelegant, leicht absurd und vollkommen deterministisch. Fügen Sie der VM vor der Migration eine winzige Dummy-Disk über einen VirtIO-SCSI-Controller hinzu. Ein Gigabyte reicht völlig, denn die Disk spielt keine Rolle, der Controller schon.

Allein diese Handlung zwingt Windows, die Hardware zu enumerieren, den Treiber zu laden und ihn als beim Booten erforderlich zu markieren. Der Treiber ist damit installiert und gleichzeitig vertrauenswürdig, und nach der Migration bootet Windows sauber, weil es bereits weiß, was es vor sich hat.

Online streiten Leute über DISM, Offline-Registry-Injection, das Skripten des Treiber-Stores und allerlei clevere Automatisierung. Manches davon funktioniert meistens. Das hier funktioniert fast immer, besonders bei älteren Windows-Server-Builds, die Jahre an Patches und Upgrades gesehen haben. Es ist hässlich und langweilig, und es spart Stunden.

Warum der Import-Wizard keine Magie ist

Der native Import-Wizard von Proxmox ist wirklich gut. Für kleine bis mittlere VMs kommt er einer One-Click-Erfahrung nahe. Webserver, App-Knoten und Utility-Boxen laufen ohne Drama durch.

Der Ärger beginnt, wenn Disks wirklich groß werden. Sobald Sie ins Multi-Terabyte-Territorium vorstoßen, besonders bei Sparse-VMDKs hinter Datenbanken, verlangsamt sich der Wizard zum Kriechen. Er verbringt Zeit damit, leeren Platz zu übersetzen, den eigentlich niemand braucht. Genau da gewinnen die altbewährten Tools.

Für die größten Systeme gingen wir offline und nutzten Clonezilla, um nur die genutzten Blöcke zu kopieren. Dieselbe 10-GbE-Verbindung, eine radikal andere Erfahrung, weniger Warten, weniger Überraschungen.

Andere schwören für diesen Schritt auf Veeam, besonders wenn es schon in der Umgebung vorhanden ist. Entscheidend ist das Gespür dafür, wann die glänzende Oberfläche aufhört, Ihr Freund zu sein.

Was eine Windows-Migration außer Daten noch verändert

Das ist die Denkweisen-Verschiebung, auf die es am meisten ankommt. Windows zwischen Hypervisoren zu verschieben heißt Disks kopieren und dabei virtuelle Hardware verändern, auf eine Weise, die Windows unbedingt bemerkt: Storage-Controller, Boot-Reihenfolge, Timing beim Laden der Treiber und Registry-Flags, an die Sie nie denken, bis sie alles zum Einsturz bringen.

VMware hat Admins jahrelang von den meisten dieser Dinge abgeschirmt. Proxmox tut das nicht, und das ist kein Makel. Es bedeutet nur, dass die Migrationsphase mehr Respekt verlangt.

Sobald Windows auf Proxmox läuft und stabil ist, ist es solide. Die Performance ist exzellent, VirtIO glänzt. Die Probleme sind ins Cutover-Fenster vorverlagert, wo sich jeder Fehler lauter und stressiger anfühlt, als er es wahrscheinlich sollte.

Die Erleichterung nach einem sauberen ersten Boot

Es gibt einen bestimmten Moment während dieser Migrationen, der Ihnen im Gedächtnis bleibt. Sie klicken auf Start, die Konsole öffnet sich, das Windows-Logo erscheint, die rotierenden Punkte drehen weiter. Kein Bluescreen, kein automatischer Neustart. Irgendwann erscheint die Login-Aufforderung, als wäre nie etwas Dramatisches passiert. Das ist der Moment, in dem Sie endlich durchatmen.

An diesem Punkt fühlen sich das Entfernen der VMware-Tools, das Aufräumen der Geräte und das Performance-Tuning routinemäßig an. Der schwere Teil liegt bereits hinter Ihnen.

Proxmox zeigt die Realität, die VMware verdeckt hat

VMware zu entkommen ist technisch weniger anspruchsvoll, als viele glauben. Schwieriger ist es, Gewohnheiten zu verlernen, die sich dank VMware sicher angefühlt haben.

Proxmox legt die Realität offen. Cluster brauchen Low-Latency-Verbindungen, Windows muss seinen Boot-Controller sehen, bevor es zustimmt, ihm zu vertrauen, und große Disks brauchen das richtige Migrationstool. Nichts davon ist exotisch. Es ist nur leicht zu unterschätzen, bis Sie um 2 Uhr morgens auf einen Bluescreen starren.

Wenn es eine Erkenntnis gibt, dann diese: Planen Sie zuerst für Windows und behandeln Sie es wie den zerbrechlichen, sturen Gast, der es ist. Tun Sie das, und der Rest der Migration fühlt sich plötzlich viel weniger beängstigend an. Sobald Sie auf der anderen Seite sind, merken Sie vielleicht, dass das Verlassen von VMware leichter war als die Aufgabe, Windows zum Mitfahren zu überreden.