Flyttet en maskin fra VMware og den starter ikke: disken er der, veien dit er det ikke

Importen er ferdig, disken står i listen, maskinen starter, og så stopper den med en melding om en oppstartsenhet den ikke når. Første innskytelse er at noe gikk tapt under konverteringen. Nesten alltid har ingenting gått tapt.

Disken ligger der den skal. Det som er endret, er veien dit.

Hvorfor det skjer

En virtuell maskin snakker ikke med en disk. Den snakker med en diskkontroller, og kontrolleren er en del av det hypervisoren viser den. VMware viste én type. Proxmox viser en annen.

Det ville vært harmløst hvis gjesten lastet enhver driver den noen gang kunne trenge. Det gjør den ikke. Et operativsystem laster bare et lite sett drivere før det har tilgang til sin egen disk, og det settet ble bestemt den dagen det ble installert. Er ikke kontrolleren foran disken med der, ser gjesten ingenting å starte fra, og den sier det på den eneste måten den kan: det finnes ingen oppstartsenhet.

Symptomet peker altså på disken, og årsaken ligger ett lag foran.

To ulike feil som ligner på hverandre

De behandles som ett problem, og det er de ikke.

Ingen oppstartsenhet i det hele tatt. Ofte er det fastvaren og ikke kontrolleren. En maskin laget under EFI starter ikke under en eldre BIOS, og omvendt likeså. Ingenting er galt med disken; maskinen startes på en måte den aldri ble installert for.

Oppstarten begynner og stopper så med klage på oppstartsenheten. Det er kontrollertilfellet. Fastvaren stemte, lasteren kjørte, og så nådde kjernen ikke disken den ble anvist.

Å skille disse to før du rører noe, sparer hele ettermiddagen, for botemidlene er forskjellige, og å bruke feil legger et andre symptom oppå det første.

Tre spørsmål før du rører noe

Er disken virkelig koblet til maskinen? Se i maskinens oppsett, ikke i lagringen. En importert disk kan finnes på lagringen uten å være koblet, og det er en to sekunders retting som ser ut som en katastrofe.

Under hvilken fastvare ble denne maskinen installert? Kommer den fra et EFI-miljø, trenger den en, og den trenger også et sted å oppbevare oppstartsoppføringene sine.

Har gjesten i det hele tatt driveren for den nye kontrolleren? Ikke "er den installert", men "finnes den inne i det diskbildet". En Windows-maskin som aldri har møtt en VirtIO-kontroller, har ikke den driveren, og den kan ikke hente den så lenge den ikke starter.

Veien som forblir reverserbar

Det finnes to framgangsmåter, og de er ikke like trygge.

Gi gjesten en kontroller den allerede kjenner. Koble disken til et grensesnitt gjesten har støttet siden installasjonsdagen, start normalt, installer den nye driveren fra det kjørende systemet, slå av, og bytt så kontroller. Hvert steg er lite, og hvert kan angres.

Trikset som gjør dette smertefritt: koble til et andre, bittelite disk av den nye kontrollertypen før byttet. Gjesten starter på den gamle veien, ser ukjent maskinvare og lar deg installere driveren i ro og mak. Deretter går byttet av den ekte disken udramatisk, fordi driveren allerede er der.

Injiser driveren inn i bildet utenfra. Raskere, og det virker, men hvis det ikke virker, sitter du igjen med å feilsøke et bilde som nå er et annet enn det du startet med. Det er riktig verktøy når du har mange maskiner og en kjent oppskrift. Det er feil verktøy for den første.

⚠️ Endre én ting av gangen. Fastvare og kontroller sammen er den vanligste måten å gjøre et løsbart problem uklart på: maskinen starter fortsatt ikke, og nå er det to mistenkte.

Linux-gjester: samme årsak, stillere symptom

Det samme skjer, og det leses annerledes. Oppstartslasteren kjører, og så blir systemet stående og vente på en rotenhet som aldri dukker opp. Grunnen er identisk: det tidlige oppstartsbildet ble bygget uten driveren for den nye kontrolleren, fordi den aldri trengtes på den gamle hypervisoren.

Botemiddelet har samme form. Start fra et redningsbilde, bygg det tidlige oppstartsbildet på nytt med driveren inkludert, og bytt kontroller først etterpå.

Hva du ikke bør gjøre

Ikke bygg maskinen på nytt og koble den gamle disken til den. Den nye maskinen får samme kontroller og samme resultat, og nå har du to maskiner å holde styr på.

Ikke slett kildemaskinen ennå. Migreringen er ferdig når den nye har startet, gjort ekte arbeid og blitt sikkerhetskopiert. Ikke når kopieringen er ferdig.

Ikke bli overrasket over hurtigstart senere. En Windows-gjest som er slått av med hurtigstart på, slår seg ikke helt av, så en maskinvareendring gjort i den tilstanden møter et system som tror det gjenopptar i stedet for å starte.

Hva Atlas gjør

Atlas setter de to tingene problemet lever mellom på samme skjerm. Maskinens maskinvarevisning viser disken, kontrolleren den henger på og fastvareinnstillingen sammen, slik at spørsmålet "hvilken av de to er feil" besvares ved å se i stedet for å prøve.

Ressurskjeden svarer også direkte på det første av de tre spørsmålene: kartet tegner fra maskinen ned til den fysiske disken, så en disk som er importert men aldri koblet, mangler synlig i kjeden i stedet for å gjemme seg i en lagringsliste.

Før en slik endring brukes, tar Atlas et øyeblikksbilde, slik at den reverserbare veien forblir reverserbar selv om gjesten reagerer dårlig. De berørte ressursene listes opp før kjøringen, og det er nettopp det som gjør "én ting av gangen" gjennomførbart i stedet for bare fornuftig.