Flyttade en maskin från VMware och den startar inte: disken finns, vägen dit gör det inte

Importen är klar, disken syns i listan, maskinen startar, och sedan stannar den med ett meddelande om en startenhet den inte når. Första ingivelsen är att något gick förlorat i konverteringen. Nästan alltid har ingenting gått förlorat.

Disken ligger där den ska. Det som ändrades är vägen dit.

Varför det händer

En virtuell maskin pratar inte med en disk. Den pratar med en diskkontroller, och kontrollern är en del av det som hypervisorn visar den. VMware visade en sort. Proxmox visar en annan.

Det vore harmlöst om gästen laddade varje drivrutin den någonsin kunde behöva. Det gör den inte. Ett operativsystem laddar bara en liten uppsättning drivrutiner innan det har tillgång till sin egen disk, och den uppsättningen bestämdes den dag det installerades. Finns inte kontrollern framför disken där, ser gästen ingenting att starta från, och den säger det på det enda sätt den kan: det finns ingen startenhet.

Symptomet pekar alltså på disken och orsaken ligger ett lager framför.

Två olika fel som liknar varandra

De behandlas som ett problem och det är de inte.

Ingen startenhet alls. Ofta är det firmware och inte kontrollern. En maskin skapad under EFI startar inte under ett äldre BIOS, och tvärtom likaså. Inget är fel med disken; maskinen startas på ett sätt den aldrig installerades för.

Starten börjar och stannar sedan med klagomål om startenheten. Det är kontrollerfallet. Firmware stämde, laddaren kördes, och sedan nådde kärnan inte den disk den anvisats.

Att skilja dessa två åt innan du rör något sparar hela eftermiddagen, för botemedlen skiljer sig och att tillämpa fel lägger ett andra symptom ovanpå det första.

Tre frågor innan du rör något

Sitter disken verkligen kopplad till maskinen? Titta i maskinens konfiguration, inte i lagringen. En importerad disk kan finnas på lagringen utan att vara kopplad, och det är en tvåsekunderskorrigering som ser ut som en katastrof.

Under vilken firmware installerades den här maskinen? Kommer den från en EFI-miljö behöver den en, och den behöver också en plats att förvara sina startposter på.

Har gästen ens drivrutinen för den nya kontrollern? Inte "är den installerad" utan "finns den inuti den diskavbilden". En Windows-maskin som aldrig mött en VirtIO-kontroller har inte den drivrutinen, och den kan inte hämta den så länge den inte startar.

Vägen som förblir vändbar

Det finns två angreppssätt och de är inte lika säkra.

Ge gästen en kontroller den redan känner. Koppla disken till ett gränssnitt som gästen stött sedan installationsdagen, starta normalt, installera den nya drivrutinen inifrån det körande systemet, stäng av, och byt sedan kontroller. Varje steg är litet och varje går att ångra.

Knepet som gör det smärtfritt: koppla före bytet en andra, pytteliten disk av den nya kontrollertypen. Gästen startar på den gamla vägen, ser okänd hårdvara och låter dig installera dess drivrutin i lugn och ro. Sedan går bytet av den riktiga disken odramatiskt, eftersom drivrutinen redan finns där.

Injicera drivrutinen i avbilden utifrån. Snabbare och det fungerar, men om det inte fungerar återstår att felsöka en avbild som nu är en annan än den du började med. Det är rätt verktyg när du har många maskiner och ett känt recept. Det är fel verktyg för den första.

⚠️ Ändra en sak i taget. Firmware och kontroller tillsammans är det vanligaste sättet att göra ett lösbart problem oklart: maskinen startar fortfarande inte och nu finns det två misstänkta.

Linux-gäster: samma orsak, tystare symptom

Samma sak händer och det läses annorlunda. Startladdaren körs, sedan blir systemet stående och väntar på en rotenhet som aldrig dyker upp. Skälet är identiskt: den tidiga startavbilden byggdes utan drivrutinen för den nya kontrollern, eftersom den aldrig behövdes på den gamla hypervisorn.

Botemedlet har samma form. Starta från en räddningsavbild, bygg om den tidiga startavbilden med drivrutinen inkluderad, och byt kontroller först därefter.

Vad du inte ska göra

Bygg inte om maskinen och koppla den gamla disken till den. Den nya maskinen får samma kontroller och samma resultat, och nu har du två maskiner att hålla reda på.

Radera inte källmaskinen än. Migreringen är klar när den nya har startat, gjort riktigt arbete och säkerhetskopierats. Inte när kopieringen är färdig.

Bli inte överraskad av snabbstart senare. En Windows-gäst som stängts av med snabbstart påslagen stängs inte av helt, så en hårdvaruändring gjord i det läget möter ett system som tror att det återupptar i stället för att starta.

Vad Atlas gör

Atlas lägger de två saker som problemet lever mellan på samma skärm. Maskinens hårdvaruvy visar disken, kontrollern den sitter på och firmwareinställningen tillsammans, så frågan "vilken av de två är fel" besvaras genom att titta i stället för att prova.

Resurskedjan svarar också direkt på den första av de tre frågorna: kartan ritar från maskinen ner till den fysiska disken, så en disk som importerats men aldrig kopplats saknas synligt i kedjan i stället för att gömma sig i en lagringslista.

Innan en sådan ändring tillämpas tar Atlas en snapshot, så att den vändbara vägen förblir vändbar även om gästen reagerar illa. De berörda resurserna listas före körningen, och det är just det som gör "en sak i taget" genomförbart i stället för bara klokt.