Macchina migrata da VMware e non si avvia: il disco c'è, la strada per arrivarci no

L'importazione è finita, il disco compare nell'elenco, la macchina parte, e poi si ferma con un messaggio su un dispositivo di avvio che non riesce a raggiungere. Il primo istinto è che qualcosa si sia perso nella conversione. Quasi sempre non si è perso nulla.

Il disco è dove deve essere. Quello che è cambiato è la strada che porta a lui.

Perché succede

Una macchina virtuale non parla con un disco. Parla con un controller di dischi, e il controller fa parte di ciò che l'hypervisor le mostra. VMware ne mostrava un tipo. Proxmox ne mostra un altro.

Sarebbe innocuo se l'ospite caricasse ogni driver di cui potrebbe aver bisogno. Non lo fa. Un sistema operativo carica solo un piccolo insieme di driver prima di avere accesso al proprio disco, e quell'insieme è stato deciso il giorno dell'installazione. Se il controller davanti al disco non è lì dentro, l'ospite non vede nulla da cui avviarsi, e lo dice nell'unico modo che ha: non c'è un dispositivo di avvio.

Quindi il sintomo punta al disco e la causa sta uno strato più avanti.

Due guasti diversi che si somigliano

Vengono trattati come un unico problema e non lo sono.

Nessun dispositivo di avvio. Spesso è il firmware e non il controller. Una macchina creata sotto EFI non si avvia sotto un BIOS tradizionale, e vale anche il contrario. Del disco non c'è nulla che non va; la macchina viene avviata in un modo per cui non è mai stata installata.

L'avvio inizia, poi si ferma lamentando il dispositivo di avvio. Questo è il caso del controller. Il firmware era giusto, il caricatore è partito, e poi il kernel non ha raggiunto il disco che gli era stato indicato.

Distinguere i due casi prima di toccare qualsiasi cosa salva l'intero pomeriggio, perché i rimedi sono diversi e applicare quello sbagliato aggiunge un secondo sintomo sopra il primo.

Tre domande prima di toccare qualsiasi cosa

Il disco è davvero collegato alla macchina? Guardate la configurazione della macchina, non lo storage. Un disco importato può essere presente sullo storage e non collegato, ed è una correzione di due secondi che sembra una catastrofe.

Sotto quale firmware è stata installata questa macchina? Se viene da un ambiente EFI ne ha bisogno, e ha bisogno anche di un posto dove tenere le sue voci di avvio.

L'ospite ha il driver del nuovo controller? Non "è installato" ma "esiste dentro quell'immagine disco". Una macchina Windows che non ha mai incontrato un controller VirtIO non ha quel driver, e non può andare a prenderselo finché non si avvia.

La via che resta reversibile

Ci sono due approcci e non sono ugualmente sicuri.

Date all'ospite un controller che già conosce. Collegate il disco a un'interfaccia che l'ospite supporta dal giorno dell'installazione, avviate normalmente, installate il nuovo driver dall'interno del sistema in esecuzione, spegnete, poi cambiate il controller. Ogni passo è piccolo e ognuno si può annullare.

Il trucco che rende tutto indolore: prima di cambiare, collegate un secondo disco piccolissimo del nuovo tipo di controller. L'ospite si avvia sulla vecchia strada, vede hardware sconosciuto e vi lascia installare il suo driver con calma. Poi il cambio del disco vero passa senza storia, perché il driver è già lì.

Iniettare il driver nell'immagine dall'esterno. Più veloce e funziona, ma se non funziona vi resta da indagare un'immagine ormai diversa da quella di partenza. È lo strumento giusto quando avete molte macchine e una ricetta collaudata. È quello sbagliato per la prima.

⚠️ Cambiate una cosa per volta. Firmware e controller insieme è il modo più comune di trasformare un problema risolvibile in uno confuso: la macchina continua a non avviarsi e ora ci sono due sospetti.

Ospiti Linux: stessa causa, sintomo più silenzioso

Succede la stessa cosa e si legge in modo diverso. Il caricatore di avvio parte, poi il sistema si ferma ad aspettare un dispositivo radice che non arriva mai. Il motivo è identico: l'immagine di avvio iniziale è stata costruita senza il driver del nuovo controller, perché sul vecchio hypervisor non è mai servito.

Anche il rimedio ha la stessa forma. Avviare da un'immagine di ripristino, ricostruire l'immagine di avvio iniziale includendo il driver, e solo dopo cambiare il controller.

Cosa non fare

Non ricostruite la macchina per attaccarci il vecchio disco. La nuova macchina avrà lo stesso controller e lo stesso risultato, e ora avrete due macchine da seguire.

Non cancellate ancora la macchina di partenza. La migrazione è finita quando la nuova si è avviata, ha fatto lavoro vero ed è stata messa in backup. Non quando la copia si conclude.

Non stupitevi dopo per l'avvio rapido. Un ospite Windows spento con l'avvio rapido attivo non si spegne del tutto, quindi una modifica hardware fatta in quello stato incontra un sistema che crede di riprendere e non di partire.

Cosa fa Atlas

Atlas mette sulla stessa schermata le due cose tra cui vive questo problema. La vista hardware della macchina mostra insieme il disco, il controller a cui è collegato e l'impostazione del firmware, così la domanda "quale dei due è sbagliato" si risponde guardando invece che provando.

Anche la catena delle risorse risponde direttamente alla prima delle tre domande: la mappa disegna dalla macchina fino al disco fisico, quindi un disco importato ma mai collegato manca visibilmente dalla catena invece di nascondersi in un elenco di storage.

Prima che una modifica del genere venga applicata, Atlas prende uno snapshot, così la via reversibile resta reversibile anche se l'ospite reagisce male. Le risorse coinvolte sono elencate prima dell'esecuzione, ed è proprio questo a rendere "una cosa per volta" praticabile invece che soltanto consigliabile.