Von VMware umgezogen und die Maschine startet nicht: die Platte ist da, der Weg dorthin nicht

Der häufigste Fehler nach einer VMware-Migration ist keine verlorene Platte. Es ist ein Gast, der den Controller vor der Platte nicht mehr kennt, und die Lösung bleibt bei jedem Schritt umkehrbar, solange Sie eine Sache nach der anderen ändern.

AtlasPVE ·

Dieser Eintrag beantwortet

  • vmware to proxmox inaccessible boot device
  • proxmox importierte vm startet nicht
  • esxi zu proxmox migration bootfehler
  • proxmox migrierte windows vm bluescreen
  • proxmox kein bootfähiges gerät nach import

Der Import ist fertig, die Platte wird aufgeführt, die Maschine startet, und dann bleibt sie mit einer Meldung über ein Startgerät stehen, das sie nicht erreicht. Der erste Gedanke ist, dass bei der Umwandlung etwas verloren ging. Fast immer ist nichts verloren gegangen.

Die Platte ist dort, wo sie sein soll. Was sich geändert hat, ist der Weg dorthin.

Warum das passiert

Eine virtuelle Maschine spricht nicht mit einer Platte. Sie spricht mit einem Plattencontroller, und der Controller gehört zu dem, was der Hypervisor ihr zeigt. VMware zeigte die eine Art. Proxmox zeigt eine andere.

Das wäre harmlos, wenn der Gast jeden Treiber laden würde, den er je brauchen könnte. Das tut er nicht. Ein Betriebssystem lädt nur einen kleinen Satz Treiber, bevor es Zugriff auf die eigene Platte hat, und dieser Satz wurde am Tag der Installation festgelegt. Ist der Controller vor der Platte nicht darin, sieht der Gast nichts, wovon er starten könnte, und sagt es auf die einzige Weise, die ihm bleibt: es gibt kein Startgerät.

Das Symptom zeigt also auf die Platte, und die Ursache liegt eine Schicht davor.

Zwei verschiedene Fehler, die gleich aussehen

Sie werden als ein Problem behandelt und sind es nicht.

Überhaupt kein Startgerät. Oft ist es die Firmware und nicht der Controller. Eine unter EFI erstellte Maschine startet nicht unter einem älteren BIOS, und umgekehrt genauso. An der Platte ist nichts falsch; die Maschine wird auf eine Weise gestartet, für die sie nie installiert wurde.

Der Start beginnt und bleibt dann beim Startgerät stehen. Das ist der Controller-Fall. Die Firmware stimmte, der Lader lief, und dann erreichte der Kernel die Platte nicht, die ihm genannt wurde.

Diese beiden vor jeder Änderung auseinanderzuhalten spart den ganzen Nachmittag, denn die Lösungen sind verschieden, und die falsche anzuwenden setzt dem vorhandenen Symptom ein zweites obendrauf.

Drei Fragen, bevor Sie etwas anfassen

Ist die Platte wirklich an der Maschine angehängt? Schauen Sie in die Konfiguration der Maschine, nicht in den Speicher. Eine importierte Platte kann im Speicher vorhanden und trotzdem nicht angehängt sein, und das ist eine Zwei-Sekunden-Korrektur, die wie eine Katastrophe aussieht.

Unter welcher Firmware wurde diese Maschine installiert? Kommt sie aus einer EFI-Umgebung, braucht sie eine, und sie braucht auch einen Ort für ihre Starteinträge.

Hat der Gast den Treiber für den neuen Controller überhaupt? Nicht "ist er installiert", sondern "existiert er in diesem Plattenabbild". Eine Windows-Maschine, die nie einem VirtIO-Controller begegnet ist, hat diesen Treiber nicht, und sie kann ihn nicht holen, solange sie nicht startet.

Der Weg, der umkehrbar bleibt

Es gibt zwei Ansätze, und sie sind nicht gleich sicher.

Geben Sie dem Gast einen Controller, den er schon kennt. Hängen Sie die Platte an eine Schnittstelle, die der Gast seit dem Installationstag unterstützt, starten Sie normal, installieren Sie den neuen Treiber aus dem laufenden System heraus, fahren Sie herunter, und wechseln Sie dann den Controller. Jeder Schritt ist klein und jeder lässt sich rückgängig machen.

Der Kniff, der das mühelos macht: hängen Sie vor dem Wechsel eine zweite, winzige Platte am neuen Controllertyp an. Der Gast startet auf dem alten Weg, sieht unbekannte Hardware und lässt Sie deren Treiber in Ruhe installieren. Danach verläuft der Wechsel der eigentlichen Platte ereignislos, weil der Treiber schon da ist.

Den Treiber von außen in das Abbild einbringen. Schneller, und es funktioniert, aber wenn es nicht funktioniert, bleibt Ihnen ein Abbild zum Untersuchen, das nun anders ist als das, mit dem Sie angefangen haben. Bei vielen Maschinen und einem bekannten Rezept ist es das richtige Werkzeug. Für die erste ist es das falsche.

⚠️ Ändern Sie eine Sache nach der anderen. Firmware und Controller zusammen ist der häufigste Weg, ein lösbares Problem in ein unklares zu verwandeln: die Maschine startet immer noch nicht, und jetzt gibt es zwei Verdächtige.

Linux-Gäste: gleiche Ursache, leiseres Symptom

Dasselbe passiert und liest sich anders. Der Startlader läuft, dann bleibt das System stehen und wartet auf ein Wurzelgerät, das nie erscheint. Der Grund ist identisch: das frühe Startabbild wurde ohne den Treiber für den neuen Controller gebaut, weil er auf dem alten Hypervisor nie gebraucht wurde.

Die Lösung hat dieselbe Form. Von einem Rettungsabbild starten, das frühe Startabbild mit dem Treiber neu erzeugen, und erst danach den Controller wechseln.

Was Sie nicht tun sollten

Bauen Sie die Maschine nicht neu und hängen Sie die alte Platte daran. Die neue Maschine hat denselben Controller und dasselbe Ergebnis, und nun haben Sie zwei Maschinen im Blick zu behalten.

Löschen Sie die Quellmaschine noch nicht. Die Migration ist fertig, wenn die neue gestartet ist, echte Arbeit geleistet hat und gesichert wurde. Nicht, wenn das Kopieren fertig ist.

Wundern Sie sich später nicht über den Schnellstart. Ein Windows-Gast, der mit aktiviertem Schnellstart heruntergefahren wurde, fährt nicht vollständig herunter, also trifft eine in diesem Zustand vorgenommene Hardwareänderung auf ein System, das glaubt fortzusetzen statt zu starten.

Was Atlas macht

Atlas bringt die beiden Dinge, zwischen denen dieses Problem lebt, auf denselben Bildschirm. Die Hardwareansicht der Maschine zeigt die Platte, den Controller, an dem sie hängt, und die Firmwareeinstellung zusammen, sodass die Frage "welches von beiden stimmt nicht" durch Hinsehen beantwortet wird statt durch Ausprobieren.

Die Ressourcenkette beantwortet auch die erste der drei Fragen direkt: die Karte zeichnet von der Maschine bis zur physischen Platte, sodass eine importierte, aber nie angehängte Platte sichtbar in der Kette fehlt, statt sich in einer Speicherliste zu verstecken.

Bevor eine solche Änderung angewandt wird, legt Atlas einen Snapshot an, damit der umkehrbare Weg umkehrbar bleibt, auch wenn der Gast schlecht reagiert. Die betroffenen Ressourcen werden vor dem Lauf aufgelistet, und genau das macht "eine Sache nach der anderen" praktikabel statt nur ratsam.

Quellen

Die eigene Dokumentation von Proxmox. Auf Englisch, und sie hat in dieser Sache das letzte Wort.

Verwandte Einträge

Wie sieht das in Atlas aus?

Zur Produktseite