Machine migrée depuis VMware et elle ne démarre pas : le disque est là, le chemin vers lui ne l'est pas

L'import est terminé, le disque apparaît dans la liste, la machine démarre, puis elle s'arrête sur un message concernant un périphérique de démarrage qu'elle n'atteint pas. Le premier réflexe est de penser que quelque chose s'est perdu pendant la conversion. Presque toujours, rien ne s'est perdu.

Le disque est là où il doit être. Ce qui a changé, c'est le chemin qui y mène.

Pourquoi cela arrive

Une machine virtuelle ne parle pas à un disque. Elle parle à un contrôleur de disque, et ce contrôleur fait partie de ce que l'hyperviseur lui présente. VMware en présentait un type. Proxmox en présente un autre.

Ce serait sans conséquence si l'invité chargeait tous les pilotes dont il pourrait un jour avoir besoin. Il ne le fait pas. Un système d'exploitation ne charge qu'un petit ensemble de pilotes avant d'accéder à son propre disque, et cet ensemble a été fixé le jour de son installation. Si le contrôleur devant le disque n'y figure pas, l'invité ne voit rien d'où démarrer, et il le dit de la seule façon qu'il connaisse : il n'y a pas de périphérique de démarrage.

Le symptôme désigne donc le disque et la cause se trouve une couche devant lui.

Deux pannes différentes qui se ressemblent

On les traite comme un seul problème, et elles n'en sont pas un.

Aucun périphérique de démarrage du tout. Souvent c'est le micrologiciel et non le contrôleur. Une machine créée sous EFI ne démarre pas sous un BIOS ancien, et l'inverse est vrai aussi. Rien ne cloche du côté du disque ; la machine est démarrée d'une manière pour laquelle elle n'a jamais été installée.

Le démarrage commence puis s'arrête en se plaignant du périphérique de démarrage. C'est le cas du contrôleur. Le micrologiciel était bon, le chargeur s'est exécuté, puis le noyau n'a pas atteint le disque qu'on lui avait indiqué.

Distinguer ces deux cas avant de toucher à quoi que ce soit sauve tout l'après-midi, car les remèdes diffèrent et appliquer le mauvais ajoute un second symptôme au premier.

Trois questions avant de toucher à quoi que ce soit

Le disque est-il vraiment rattaché à la machine ? Regardez la configuration de la machine, pas le stockage. Un disque importé peut être présent sur le stockage sans être rattaché, et c'est une correction de deux secondes qui ressemble à une catastrophe.

Sous quel micrologiciel cette machine a-t-elle été installée ? Si elle vient d'un environnement EFI, il lui en faut un, et il lui faut aussi un endroit où conserver ses entrées de démarrage.

L'invité possède-t-il seulement le pilote du nouveau contrôleur ? Non pas « est-il installé » mais « existe-t-il dans cette image disque ». Une machine Windows qui n'a jamais rencontré de contrôleur VirtIO ne possède pas ce pilote, et elle ne peut pas aller le chercher tant qu'elle ne démarre pas.

La voie qui reste réversible

Il y a deux approches et elles ne sont pas également sûres.

Donnez à l'invité un contrôleur qu'il connaît déjà. Rattachez le disque à une interface que l'invité prend en charge depuis le jour de son installation, démarrez normalement, installez le nouveau pilote depuis le système en marche, éteignez, puis changez le contrôleur. Chaque étape est petite et chacune peut être annulée.

L'astuce qui rend cela indolore : avant de basculer, rattachez un deuxième disque, minuscule, du nouveau type de contrôleur. L'invité démarre par l'ancien chemin, voit du matériel inconnu et vous laisse installer son pilote tranquillement. Ensuite le changement du vrai disque se passe sans histoire, parce que le pilote est déjà là.

Injecter le pilote dans l'image depuis l'extérieur. Plus rapide et cela fonctionne, mais si cela ne fonctionne pas il vous reste à déboguer une image désormais différente de celle du départ. C'est le bon outil quand vous avez beaucoup de machines et une recette éprouvée. C'est le mauvais outil pour la première.

⚠️ Ne changez qu'une chose à la fois. Micrologiciel et contrôleur ensemble, c'est la façon la plus courante de transformer un problème soluble en problème flou : la machine ne démarre toujours pas et il y a maintenant deux suspects.

Invités Linux : même cause, symptôme plus discret

La même chose se produit et se lit autrement. Le chargeur de démarrage s'exécute, puis le système reste bloqué à attendre un périphérique racine qui n'arrive jamais. La raison est identique : l'image de démarrage initiale a été construite sans le pilote du nouveau contrôleur, parce que sur l'ancien hyperviseur il n'a jamais servi.

Le remède a la même forme. Démarrer depuis une image de secours, reconstruire l'image de démarrage initiale en y incluant le pilote, et seulement ensuite changer le contrôleur.

Ce qu'il ne faut pas faire

Ne reconstruisez pas la machine pour y rattacher l'ancien disque. La nouvelle machine aura le même contrôleur et le même résultat, et vous aurez désormais deux machines à suivre.

Ne supprimez pas encore la machine source. La migration est terminée quand la nouvelle a démarré, a fait du vrai travail et a été sauvegardée. Pas quand la copie s'achève.

Ne soyez pas surpris plus tard par le démarrage rapide. Un invité Windows éteint avec le démarrage rapide activé ne s'éteint pas complètement, donc une modification matérielle faite dans cet état rencontre un système qui croit reprendre et non démarrer.

Ce que fait Atlas

Atlas met sur le même écran les deux choses entre lesquelles ce problème vit. La vue matérielle de la machine montre ensemble le disque, le contrôleur auquel il est rattaché et le réglage de micrologiciel, si bien que la question « lequel des deux est faux » se répond en regardant plutôt qu'en essayant.

La chaîne de ressources répond aussi directement à la première des trois questions : la carte dessine de la machine jusqu'au disque physique, donc un disque importé mais jamais rattaché manque visiblement dans la chaîne au lieu de se cacher dans une liste de stockage.

Avant qu'une telle modification soit appliquée, Atlas prend un instantané, pour que la voie réversible le reste même si l'invité réagit mal. Les ressources concernées sont listées avant l'exécution, et c'est justement ce qui rend « une chose à la fois » praticable plutôt que seulement recommandable.