Machine verhuisd vanaf VMware en hij start niet: de schijf is er, de weg ernaartoe niet

De import is klaar, de schijf staat in de lijst, de machine start, en dan blijft hij staan met een melding over een opstartapparaat dat hij niet bereikt. De eerste ingeving is dat er iets verloren ging bij de conversie. Bijna altijd is er niets verloren gegaan.

De schijf is waar hij hoort. Wat veranderde is de weg ernaartoe.

Waarom dit gebeurt

Een virtuele machine praat niet met een schijf. Hij praat met een schijfcontroller, en die controller hoort bij wat de hypervisor hem laat zien. VMware liet de ene soort zien. Proxmox laat een andere zien.

Dat zou onschuldig zijn als de gast elke driver laadde die hij ooit nodig kon hebben. Dat doet hij niet. Een besturingssysteem laadt maar een kleine set drivers voordat het toegang tot zijn eigen schijf heeft, en die set werd bepaald op de dag dat het geïnstalleerd werd. Zit de controller vóór de schijf daar niet in, dan ziet de gast niets om vanaf te starten, en hij zegt dat op de enige manier die hij kent: er is geen opstartapparaat.

Het symptoom wijst dus naar de schijf en de oorzaak ligt er een laag vóór.

Twee verschillende storingen die op elkaar lijken

Ze worden als één probleem behandeld en dat zijn ze niet.

Helemaal geen opstartapparaat. Vaak is het de firmware en niet de controller. Een machine die onder EFI is gemaakt start niet onder een ouderwetse BIOS, en andersom net zo. Aan de schijf mankeert niets; de machine wordt gestart op een manier waarvoor hij nooit is geïnstalleerd.

Het starten begint en stopt dan klagend over het opstartapparaat. Dat is het controllergeval. De firmware klopte, de lader draaide, en daarna bereikte de kernel de schijf niet die hem was aangewezen.

Deze twee uit elkaar houden vóór u iets aanraakt scheelt de hele middag, want de oplossingen verschillen en de verkeerde toepassen legt een tweede symptoom bovenop het eerste.

Drie vragen voordat u iets aanraakt

Zit de schijf echt aan de machine gekoppeld? Kijk in de configuratie van de machine, niet in de opslag. Een geïmporteerde schijf kan op de opslag aanwezig zijn en toch niet gekoppeld, en dat is een correctie van twee seconden die op een ramp lijkt.

Onder welke firmware is deze machine geïnstalleerd? Komt hij uit een EFI-omgeving, dan heeft hij er een nodig, en hij heeft ook een plek nodig om zijn opstartvermeldingen te bewaren.

Heeft de gast de driver voor de nieuwe controller überhaupt? Niet "is hij geïnstalleerd" maar "bestaat hij binnen dat schijfbestand". Een Windows-machine die nooit een VirtIO-controller heeft ontmoet, heeft die driver niet, en hij kan hem niet ophalen zolang hij niet start.

De weg die omkeerbaar blijft

Er zijn twee aanpakken en ze zijn niet even veilig.

Geef de gast een controller die hij al kent. Koppel de schijf aan een interface die de gast sinds zijn installatiedag ondersteunt, start normaal op, installeer de nieuwe driver vanuit het draaiende systeem, sluit af, en wissel dan de controller. Elke stap is klein en elke stap is terug te draaien.

De truc die dit pijnloos maakt: koppel vóór het wisselen een tweede, piepklein schijfje van het nieuwe controllertype. De gast start via de oude weg, ziet onbekende hardware en laat u de driver ervoor rustig installeren. Daarna verloopt het wisselen van de echte schijf zonder verhaal, want de driver is er al.

De driver van buitenaf in het schijfbestand injecteren. Sneller en het werkt, maar als het niet werkt houdt u een bestand over om uit te pluizen dat nu anders is dan waarmee u begon. Het is het juiste gereedschap bij veel machines en een bekend recept. Het is het verkeerde voor de eerste.

⚠️ Verander één ding tegelijk. Firmware en controller samen is de meest voorkomende manier om een oplosbaar probleem in een onduidelijk probleem te veranderen: de machine start nog steeds niet en nu zijn er twee verdachten.

Linux-gasten: dezelfde oorzaak, stiller symptoom

Hetzelfde gebeurt en het leest anders. De opstartlader draait, en dan blijft het systeem wachten op een hoofdapparaat dat nooit verschijnt. De reden is identiek: het vroege opstartbestand is gebouwd zonder de driver voor de nieuwe controller, omdat die op de oude hypervisor nooit nodig was.

De oplossing heeft dezelfde vorm. Start vanaf een reddingsbestand, bouw het vroege opstartbestand opnieuw mét de driver erin, en wissel pas daarna de controller.

Wat u niet moet doen

Bouw de machine niet opnieuw om er de oude schijf aan te hangen. De nieuwe machine krijgt dezelfde controller en hetzelfde resultaat, en nu hebt u twee machines om bij te houden.

Verwijder de bronmachine nog niet. De migratie is klaar als de nieuwe is opgestart, echt werk heeft gedaan en een back-up heeft gekregen. Niet als het kopiëren klaar is.

Wees later niet verrast door snel opstarten. Een Windows-gast die met snel opstarten aan is afgesloten, sluit niet volledig af, dus een hardwarewijziging in die toestand treft een systeem dat denkt te hervatten in plaats van te starten.

Wat Atlas doet

Atlas zet de twee dingen waartussen dit probleem leeft op hetzelfde scherm. Het hardwareoverzicht van de machine toont de schijf, de controller waaraan hij hangt en de firmware-instelling bij elkaar, zodat de vraag "welke van de twee klopt niet" wordt beantwoord door te kijken in plaats van te proberen.

De bronketen beantwoordt ook de eerste van de drie vragen rechtstreeks: de kaart tekent van de machine tot de fysieke schijf, dus een geïmporteerde maar nooit gekoppelde schijf ontbreekt zichtbaar in de keten in plaats van zich te verstoppen in een opslaglijst.

Voordat zo'n wijziging wordt toegepast, maakt Atlas een snapshot, zodat de omkeerbare weg omkeerbaar blijft ook als de gast slecht reageert. De geraakte bronnen worden vóór de uitvoering opgesomd, en juist dat maakt "één ding tegelijk" uitvoerbaar in plaats van alleen verstandig.