Migré una máquina desde VMware y no arranca: el disco está, el camino hasta él no

La importación terminó, el disco aparece en la lista, la máquina arranca, y luego se detiene con un mensaje sobre un dispositivo de arranque que no alcanza. El primer instinto es pensar que algo se perdió en la conversión. Casi siempre no se perdió nada.

El disco está donde debe estar. Lo que cambió es el camino hasta él.

Por qué pasa

Una máquina virtual no habla con un disco. Habla con un controlador de disco, y el controlador forma parte de lo que el hipervisor le presenta. VMware presentaba un tipo. Proxmox presenta otro.

Eso sería inofensivo si el invitado cargara todos los controladores que pudiera llegar a necesitar. No lo hace. Un sistema operativo carga solo un conjunto pequeño de controladores antes de tener acceso a su propio disco, y ese conjunto se decidió el día en que se instaló. Si el controlador que hay delante del disco no está ahí, el invitado no ve nada desde donde arrancar, y lo dice de la única forma que puede: no hay dispositivo de arranque.

Así que el síntoma apunta al disco y la causa está una capa por delante.

Dos fallos distintos que se parecen

Se tratan como un solo problema y no lo son.

Ningún dispositivo de arranque. A menudo es el firmware y no el controlador. Una máquina creada bajo EFI no arranca bajo una BIOS antigua, y al revés también. Nada falla en el disco; la máquina se está arrancando de una forma para la que nunca se instaló.

El arranque empieza y luego se detiene quejándose del dispositivo de arranque. Ese es el caso del controlador. El firmware era correcto, el cargador se ejecutó, y después el núcleo no alcanzó el disco que le habían indicado.

Distinguir estos dos casos antes de tocar nada salva la tarde entera, porque los remedios son distintos y aplicar el equivocado añade un segundo síntoma encima del primero.

Tres preguntas antes de tocar nada

¿El disco está realmente conectado a la máquina? Mire la configuración de la máquina, no el almacenamiento. Un disco importado puede estar presente en el almacenamiento y sin conectar, y esa es una corrección de dos segundos que parece una catástrofe.

¿Con qué firmware se instaló esta máquina? Si viene de un entorno EFI lo necesita, y también necesita un sitio donde guardar sus entradas de arranque.

¿Tiene el invitado el controlador del nuevo dispositivo siquiera? No "está instalado" sino "existe dentro de esa imagen de disco". Una máquina Windows que nunca se ha encontrado con un controlador VirtIO no lo tiene, y no puede ir a buscarlo mientras no arranque.

La vía que sigue siendo reversible

Hay dos enfoques y no son igual de seguros.

Déle al invitado un controlador que ya conozca. Conecte el disco a una interfaz que el invitado admita desde el día de su instalación, arranque con normalidad, instale el nuevo controlador desde el sistema en marcha, apague, y después cambie el controlador. Cada paso es pequeño y cada uno se puede deshacer.

El truco que lo hace indoloro: antes de cambiar, conecte un segundo disco diminuto del nuevo tipo de controlador. El invitado arranca por el camino viejo, ve hardware desconocido y le deja instalar su controlador con calma. Después el cambio del disco de verdad transcurre sin incidentes, porque el controlador ya está ahí.

Inyectar el controlador en la imagen desde fuera. Más rápido y funciona, pero si no funciona le queda depurar una imagen que ya es distinta de la de partida. Es la herramienta correcta cuando tiene muchas máquinas y una receta conocida. Es la equivocada para la primera.

⚠️ Cambie una cosa cada vez. Firmware y controlador a la vez es la forma más común de convertir un problema resoluble en uno confuso: la máquina sigue sin arrancar y ahora hay dos sospechosos.

Invitados Linux: misma causa, síntoma más callado

Ocurre lo mismo y se lee distinto. El cargador de arranque se ejecuta, y luego el sistema se queda esperando un dispositivo raíz que nunca aparece. El motivo es idéntico: la imagen de arranque temprana se construyó sin el controlador del nuevo dispositivo, porque en el hipervisor anterior nunca hizo falta.

El remedio tiene la misma forma. Arrancar desde una imagen de rescate, reconstruir la imagen de arranque temprana incluyendo el controlador, y solo entonces cambiar el controlador.

Lo que no hay que hacer

No reconstruya la máquina para conectarle el disco viejo. La nueva máquina tendrá el mismo controlador y el mismo resultado, y ahora tendrá dos máquinas que seguir.

No borre todavía la máquina de origen. La migración termina cuando la nueva ha arrancado, ha hecho trabajo real y se ha respaldado. No cuando acaba la copia.

No se sorprenda después con el inicio rápido. Un invitado Windows apagado con el inicio rápido activado no se apaga del todo, así que un cambio de hardware hecho en ese estado se encuentra con un sistema que cree reanudar y no arrancar.

Qué hace Atlas

Atlas pone en la misma pantalla las dos cosas entre las que vive este problema. La vista de hardware de la máquina muestra juntos el disco, el controlador al que está conectado y el ajuste de firmware, de modo que la pregunta "cuál de los dos está mal" se responde mirando en vez de probando.

La cadena de recursos también responde directamente a la primera de las tres preguntas: el mapa dibuja desde la máquina hasta el disco físico, así que un disco importado pero nunca conectado falta visiblemente en la cadena en lugar de esconderse en una lista de almacenamiento.

Antes de aplicar un cambio así, Atlas toma una instantánea, para que la vía reversible siga siéndolo aunque el invitado reaccione mal. Los recursos afectados se listan antes de ejecutar, y eso es justo lo que hace que "una cosa cada vez" sea practicable y no solo aconsejable.