Flyttede en maskine fra VMware, og den starter ikke: disken er der, vejen dertil er det ikke

Importen er færdig, disken står på listen, maskinen starter, og så stopper den med en besked om en opstartsenhed, den ikke kan nå. Den første indskydelse er, at noget gik tabt under konverteringen. Næsten altid er intet gået tabt.

Disken ligger, hvor den skal. Det, der er ændret, er vejen dertil.

Hvorfor det sker

En virtuel maskine taler ikke med en disk. Den taler med en diskcontroller, og controlleren er en del af det, hypervisoren viser den. VMware viste én slags. Proxmox viser en anden.

Det ville være harmløst, hvis gæsten indlæste enhver driver, den nogensinde kunne få brug for. Det gør den ikke. Et styresystem indlæser kun et lille sæt drivere, før det har adgang til sin egen disk, og det sæt blev afgjort den dag, det blev installeret. Er controlleren foran disken ikke med der, ser gæsten intet at starte fra, og den siger det på den eneste måde, den kan: der er ingen opstartsenhed.

Symptomet peger altså på disken, og årsagen ligger et lag foran.

To forskellige fejl, der ligner hinanden

De behandles som ét problem, og det er de ikke.

Slet ingen opstartsenhed. Ofte er det firmwaren og ikke controlleren. En maskine skabt under EFI starter ikke under en ældre BIOS, og omvendt ligeså. Der er intet galt med disken; maskinen startes på en måde, den aldrig blev installeret til.

Opstarten begynder og stopper så med at brokke sig over opstartsenheden. Det er controllertilfældet. Firmwaren passede, indlæseren kørte, og så nåede kernen ikke den disk, den fik anvist.

At skelne de to fra hinanden, før du rører noget, sparer hele eftermiddagen, for løsningerne er forskellige, og at bruge den forkerte lægger et andet symptom oven på det første.

Tre spørgsmål, før du rører noget

Sidder disken virkelig tilsluttet maskinen? Se i maskinens opsætning, ikke i lagringen. En importeret disk kan være til stede på lagringen uden at være tilsluttet, og det er en to sekunders rettelse, der ligner en katastrofe.

Under hvilken firmware blev denne maskine installeret? Kommer den fra et EFI-miljø, har den brug for en, og den har også brug for et sted at gemme sine opstartsposter.

Har gæsten overhovedet driveren til den nye controller? Ikke "er den installeret", men "findes den inde i det diskbillede". En Windows-maskine, der aldrig har mødt en VirtIO-controller, har ikke den driver, og den kan ikke hente den, så længe den ikke starter.

Vejen, der forbliver reversibel

Der er to fremgangsmåder, og de er ikke lige sikre.

Giv gæsten en controller, den allerede kender. Tilslut disken til en grænseflade, gæsten har understøttet siden installationsdagen, start normalt, installer den nye driver fra det kørende system, luk ned, og skift så controller. Hvert skridt er lille, og hvert kan fortrydes.

Tricket, der gør det smertefrit: tilslut før skiftet en anden, bitte lille disk af den nye controllertype. Gæsten starter ad den gamle vej, ser ukendt hardware og lader dig installere dens driver i ro og mag. Derefter forløber skiftet af den rigtige disk udramatisk, fordi driveren allerede er der.

Indsprøjt driveren i billedet udefra. Hurtigere, og det virker, men hvis det ikke virker, står du tilbage med at fejlsøge et billede, der nu er et andet end det, du startede med. Det er det rigtige værktøj, når du har mange maskiner og en kendt opskrift. Det er det forkerte til den første.

⚠️ Skift én ting ad gangen. Firmware og controller sammen er den hyppigste måde at gøre et løseligt problem uklart på: maskinen starter stadig ikke, og nu er der to mistænkte.

Linux-gæster: samme årsag, mere stille symptom

Det samme sker, og det læses anderledes. Opstartsindlæseren kører, og så bliver systemet stående og venter på en rodenhed, der aldrig dukker op. Grunden er identisk: det tidlige opstartsbillede blev bygget uden driveren til den nye controller, fordi den aldrig var nødvendig på den gamle hypervisor.

Løsningen har samme form. Start fra et redningsbillede, byg det tidlige opstartsbillede igen med driveren inkluderet, og skift først derefter controller.

Hvad du ikke skal gøre

Byg ikke maskinen forfra og tilslut den gamle disk til den. Den nye maskine får samme controller og samme resultat, og nu har du to maskiner at holde styr på.

Slet ikke kildemaskinen endnu. Migreringen er færdig, når den nye er startet, har lavet rigtigt arbejde og er blevet sikkerhedskopieret. Ikke når kopieringen er færdig.

Bliv ikke overrasket over hurtig opstart senere. En Windows-gæst, der er lukket ned med hurtig opstart slået til, lukker ikke helt ned, så en hardwareændring foretaget i den tilstand møder et system, der tror, det genoptager i stedet for at starte.

Hvad Atlas gør

Atlas sætter de to ting, problemet lever imellem, på samme skærm. Maskinens hardwarevisning viser disken, den controller den sidder på, og firmwareindstillingen sammen, så spørgsmålet "hvilken af de to er forkert" besvares ved at kigge i stedet for at prøve.

Ressourcekæden svarer også direkte på det første af de tre spørgsmål: kortet tegner fra maskinen ned til den fysiske disk, så en disk, der er importeret men aldrig tilsluttet, mangler synligt i kæden i stedet for at gemme sig i en lagringsliste.

Før en sådan ændring anvendes, tager Atlas et øjebliksbillede, så den reversible vej forbliver reversibel, selv hvis gæsten reagerer dårligt. De berørte ressourcer listes før kørslen, og det er netop det, der gør "én ting ad gangen" gennemførligt i stedet for blot fornuftigt.