VMware zu entkommen ist nicht der schwere Teil — Windows auf Proxmox VE zum Booten zu bringen schon

VMware zu verlassen erwies sich als die leichte Entscheidung.

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.

Nicht einmal. Nicht zweimal. Immer wieder.

Was jetzt folgt, ist keine Geschichte darüber, dass Proxmox "schlecht" oder Windows "furchtbar" ist (auch wenn es sich diesen Ruf manchmal verdient). Es geht um Annahmen. Um VMware-trainierte Instinkte. Und um eine 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 nicht das Problem — Ihr mentales Modell ist es

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. Aber es bedeutet auch, dass Windows plötzlich sehr genau weiß, wovon es bootet, und es mag keine Überraschungen.

Linux-VMs? Die zucken 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. Reichlich Bandbreite. Reichlich Spielraum. Warum 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. Es kümmert sich 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. 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.

"Empfohlen" in der Dokumentation bedeutet nicht "optional", wenn Cluster im Spiel sind — das ist die Lektion.

Dann kam Windows. Und die BSOD-Schleife.

Das ist der Teil, über den alle nur flüstern.

Sie importieren eine Windows-VM. Sie klicken auf Start. Der Boot-Bildschirm blitzt auf. Und dann: 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.

Treiber zu installieren reicht nicht. Das ist der Haken.

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. 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. Jetzt ist der Treiber nicht nur installiert. Er ist vertrauenswürdig.

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. Es ist 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, Utility-Boxen — kein Drama.

Der Ärger beginnt, wenn Disks groß werden. Wirklich groß.

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 altbewährte Tools still und leise.

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. Es geht nicht um das Tool. Es geht darum zu wissen, wann die glänzende Oberfläche aufhört, Ihr Freund zu sein.

Windows-Migrationen sind nicht nur Datenumzüge

Das ist die Denkweisen-Verschiebung, auf die es am meisten ankommt.

Windows zwischen Hypervisoren zu verschieben ist nicht nur das Kopieren von Disks. Es verändert virtuelle Hardware auf eine Weise, die Windows unbedingt bemerkt. Storage-Controller. Boot-Reihenfolge. Timing beim Laden der Treiber. 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 stille Erleichterung eines sauberen ersten Boots

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 ist nicht schwerer — es ist ehrlicher

VMware zu entkommen ist nicht die technische Herausforderung, für die Leute sie halten. Die echte Herausforderung ist, 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. 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. 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.

Und sobald Sie auf der anderen Seite sind, merken Sie vielleicht, dass der schwerste Teil gar nicht das Verlassen von VMware war. Es war, Windows davon zu überzeugen, bei der Fahrt mitzumachen.