Problemas de arranque de máquinas virtuales o AVD tras parches

Cuando una máquina virtual de Windows, Linux, Azure Virtual Desktop (AVD) o un escritorio publicado en plataformas como Citrix o VMware deja de arrancar tras instalar un parche, el susto es importante. Un simple reinicio después de una actualización puede dejar inaccesibles servidores críticos, escritorios de usuarios o laboratorios de pruebas, y en muchos casos el mensaje en pantalla no da demasiadas pistas de qué está fallando realmente.

La buena noticia es que la mayoría de estos fallos de inicio siguen ciertos patrones. Conociendo los síntomas típicos, las causas más probables y una serie de comprobaciones ordenadas, es posible recuperar muchas VMs sin tener que reinstalar el sistema operativo ni restaurar copias de seguridad completas, o al menos reducir al mínimo el tiempo de inactividad y el impacto en producción.

Problemas de arranque tras un parche: escenarios más habituales

En entornos de virtualización modernos se mezclan varios componentes: el hipervisor (ESXi, Hyper-V, XenServer, Azure, Citrix), el firmware virtual (BIOS/UEFI, Secure Boot, MOK Manager y arranque seguro). Cuando algo se rompe al arrancar después de una actualización, suele ser por una de estas razones:

1. Errores en la partición de arranque o en el BCD (en sistemas Windows): la VM muestra mensajes como “Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device” porque la partición que contiene el almacén de datos de configuración de arranque (BCD) no está activa, está dañada o no se encuentra el sector de arranque.

2. Problemas de kernel o init en Linux: tras actualizar el sistema (por ejemplo, de Linux Mint a una versión superior) o aplicar un “Actualizar todo”, el nuevo kernel no termina de iniciar y el sistema indica que falta o no se ha podido ejecutar el proceso de inicio (init), sugiriendo parámetros como init= en la línea de arranque del kernel; para estos casos consulta cómo añadir parámetros al GRUB.

3. Conflictos entre Secure Boot y parches de Windows: muy típico en Windows Server 2022 con Secure Boot habilitado sobre ciertos hosts ESXi. Después de instalar actualizaciones como KB5022842, la VM deja de arrancar, muestra violaciones de seguridad en el arranque y, en los logs de VMware, aparece el mensaje “SECUREBOOT: Image DENIED”.

4. Actualizaciones defectuosas en Windows 11 en entornos virtualizados (Azure, AVD, Citrix, Hyper-V, etc.). Algunas actualizaciones de seguridad, como KB5058405, han provocado errores de recuperación ACPI.sys con código 0xc0000098, impidiendo que el sistema arranque con normalidad; conviene además revisar guías para optimizar el arranque de Windows 11 en entornos virtuales.

5. Cambios en la configuración de inicio de la VM (sobre todo en VMware): si el archivo .nvram no conserva los ajustes de BIOS/UEFI o se ha restaurado una VM sin la configuración de arranque original, puede que ya no exista una entrada válida para el gestor de arranque (por ejemplo, grub.efi en sistemas Linux) y la máquina se quede “huérfana” sin dispositivo de arranque.

Pasos generales para diagnosticar fallos de arranque en VMs Windows

Cuando una máquina virtual de Windows no arranca tras aplicar un parche y no sabemos por dónde empezar, conviene seguir una secuencia ordenada; antes de lanzarse a reinstalar, merece la pena realizar estas comprobaciones básicas que permiten distinguir entre problemas de hipervisor, de configuración de arranque o del propio sistema operativo. Además, en entornos grandes puede ser útil automatizar el arranque de máquinas virtuales para reducir la intervención manual.

Verificar el estado de la máquina virtual en el hipervisor o portal: asegúrate de que la VM aparece como “Iniciada” o “En ejecución” en Azure, Hyper-V, ESXi, Citrix, etc. Si está apagada o en error, prueba a arrancarla desde la consola de gestión y revisa si hay mensajes específicos de fallo de encendido.

Reiniciar la VM por completo desde la consola: no confíes solo en un reinicio “suave” desde el sistema operativo (que puede ni siquiera estar operativo). Utiliza el control de energía del hipervisor o de la consola de administración (por ejemplo, las opciones de Control de energía de Citrix Director o el portal de Azure) para apagar y encender la VM, y observa la consola durante el POST y el arranque.

Usar capturas de pantalla o consola serial / diagnósticos de arranque: en Azure, por ejemplo, los diagnósticos de arranque permiten ver una captura de pantalla del estado de la VM durante el inicio. Si ves mensajes como “Boot failure”, “No bootable device” o errores de recuperación de Windows, tendrás pistas claras sobre si el problema está en la partición de arranque, en los ficheros del sistema o en el firmware virtual.

Intentar llegar, al menos, a la pantalla de “Ctrl+Alt+Supr”: si la VM nunca alcanza el típico “Press Ctrl+Alt+Del to sign in” y se queda en bucles de reparación, pantallas azules o mensajes de error de firmware, estás ante un fallo de arranque real, no de credenciales ni de red. Esto orienta hacia corrupción de BCD, problemas de drivers críticos (como ACPI.sys) o conflictos con Secure Boot.

Errores de partición de arranque y BCD en máquinas virtuales Windows

Uno de los problemas más comunes tras cambios de disco, restauraciones de backup o ciertas actualizaciones es que la partición que contiene el BCD deja de ser la activa o el propio almacén BCD se corrompe. El síntoma típico es el mensaje:

Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device

En este escenario, el sistema operativo sigue ahí, pero el firmware virtual no sabe desde dónde arrancar o no encuentra un gestor de arranque válido. La solución pasa por montar el disco en una VM de reparación, marcar la partición adecuada como activa y, si hace falta, reconstruir el BCD con las rutas correctas a la carpeta de Windows.

Crear y usar una máquina virtual de reparación: en plataformas como Azure o Hyper-V, es habitual desacoplar el disco del sistema de la VM dañada, adjuntarlo a otra VM “de reparación” y acceder a él desde allí. Este enfoque permite lanzar herramientas como DISKPART, CHKDSK y BCDEDIT sobre el disco problemático sin que interfiera el arranque.

Comprobar qué partición es la activa con DISKPART:

• Inicia un símbolo de sistema con privilegios de administrador en la VM de reparación y ejecuta diskpart.
• Lista los discos con list disk y selecciona el que corresponde al disco adjunto de la VM afectada, por ejemplo sel disk 1.
• Muestra las particiones con list partition y selecciona la partición reservada al sistema (normalmente pequeña, unos cientos de MB), por ejemplo sel partition 1.
• Ejecuta detail partition para ver si está marcada como “Active”. Si no lo está, utiliza active y vuelve a comprobar con detail partition que el cambio se ha aplicado.
• Sal de DISKPART con exit cuando hayas terminado.

Revisar y reparar el BCD: una vez confirmada la partición activa, conviene validar el contenido del BCD. Primero, ejecuta un chkdsk <letra>: /f sobre el volumen que contiene Windows para descartar errores de disco que puedan volver a corromper el almacén de arranque.

Luego, usa BCDEDIT apuntando expresamente al BCD del disco montado. El comando cambia según se trate de una VM de generación 1 (BIOS) o generación 2 (UEFI):

• Generación 1 (BIOS): bcdedit /store <letra-partición-sistema>:\boot\bcd /enum
• Generación 2 (UEFI): bcdedit /store <letra-partición-EFI>:EFI\Microsoft\boot\bcd /enum

Si el fichero \boot\bcd no existe o da error, está claro que el BCD se ha perdido o dañado y habrá que recrear las entradas. En la salida de BCDEDIT busca el identificador del cargador de arranque de Windows (la entrada cuyo “path” es \Windows\System32\winload.efi). Con ese GUID podrás ajustar las referencias:

• Definir el dispositivo del gestor de arranque ({bootmgr}) hacia la partición correcta.
• Establecer device y osdevice del identificador de Windows hacia la partición donde está la carpeta \Windows.
• Opcionalmente, activar integrityservices, desactivar recoveryenabled si quieres evitar bucles de reparación automática, y configurar bootstatuspolicy IgnoreAllFailures para forzar el arranque incluso con ciertos errores.

Una vez corregidos estos puntos, se puede volver a adjuntar el disco a la VM original y reconstruir la máquina virtual si la plataforma lo requiere (por ejemplo, recreando la VM en Azure a partir de ese disco reparado).

Bloqueos de arranque por Secure Boot y parches de Windows Server 2022

En los últimos tiempos se han visto muchos casos de servidores Windows Server 2022 que dejaron de arrancar después de instalar la actualización KB5022842 cuando estaban ejecutándose sobre ESXi 6.7 U2/U3 o ESXi 7.0.x con Secure Boot activado. El comportamiento típico es:

El servidor tarda “una eternidad” en iniciar, no responde por RDP y, al abrir la consola desde vCenter, aparece un error de violación de seguridad en el arranque de Windows. Al cabo de un rato, la VM termina entrando directamente en la BIOS/UEFI virtual, sin llegar a cargar el sistema operativo.

Muchos administradores pensaron al principio en un problema puntual de configuración o software, pero al reiniciar varias VMs con la misma combinación (Windows Server 2022 + KB5022842 + Secure Boot + ESXi 6.7/7.0), se repetía el fallo en todas. La prueba definitiva fue restaurar una copia de seguridad previa al parche: la VM arrancaba a la primera.

La parte curiosa es que el error no se manifestaba durante el reinicio asociado a la propia instalación del parche, sino en el siguiente reboot, lo que complicó aún más la identificación del culpable. En los registros de VMware (vmware.log) podía verse el mensaje:

SECUREBOOT: Image DENIED

Esto indica que la imagen de arranque de Windows no era aceptada por la base de firmas de Secure Boot del firmware virtual, de modo que se impedía el inicio por motivos de seguridad.

Soluciones definitivas publicadas por VMware y Microsoft:

• VMware resolvió el problema en el host con VMware ESXi 7.0 U3k, publicado el 21 de febrero de 2023. Los hosts con vSphere ESXi 8.0.x nunca se vieron afectados.
• Microsoft lanzó posteriormente la actualización KB5023705 (14 de marzo de 2023), que también corrige este comportamiento en Windows Server 2022.

Buenas prácticas si ya estás afectado:

Si tienes VMs Windows Server 2022 que no arrancan por este motivo, la recomendación es:

• Actualizar el host a ESXi 7.0 U3k (o superior) o mover las VMs a un host que ya ejecute esa versión.
• Aplicar la actualización de Windows KB5023705 en las VMs afectadas una vez que arranquen correctamente.
• Después de parchear el host, encender las VMs que se quedaban bloqueadas; deberían arrancar sin pasos adicionales.

Si por política o limitaciones técnicas no es posible actualizar el host ni aplicar el nuevo parche de Windows de inmediato, existe una solución temporal bastante práctica: desactivar Secure Boot en las VMs afectadas. Muchos administradores comprobaron que, simplemente quitando la marca de Secure Boot en la configuración de la VM, el sistema volvía a arrancar con normalidad, incluso con KB5022842 instalado. Eso sí, conviene ver esta medida como un workaround, no como un estado definitivo.

Actualizaciones de Windows 11, ACPI.sys y errores 0xc0000098 en entornos virtuales

Algo similar ha sucedido con ciertos parches de seguridad de Windows 11 en entornos virtualizados, especialmente en Azure Virtual Machines, Azure Virtual Desktop y plataformas como Citrix o Hyper-V. La actualización KB5058405 provocó en algunos sistemas un fallo de arranque con pantalla de recuperación mostrando:

Código de error: 0xc0000098 y referencia al archivo ACPI.sys

El archivo ACPI.sys es un controlador crítico de Windows para la gestión de energía y la configuración avanzada de hardware. Cuando falla su carga o verificación de integridad, el sistema no puede continuar el arranque. Este problema se ha visto sobre todo en Windows 11 versiones 22H2 y 23H2 ejecutándose como máquinas virtuales.

Para resolverlo, Microsoft publicó un parche de emergencia fuera de banda, KB5062170, que debe descargarse e instalarse manualmente desde el Catálogo de actualizaciones de Microsoft. Lo recomendable es:

• Aplicar KB5062170 antes de desplegar KB5058405 en entornos de producción, especialmente si estás en plataformas virtuales sensibles.
• Si ya estás afectado y la VM no arranca, usar medios de recuperación o consolas de emergencia para desinstalar temporalmente KB5058405 y poder aplicar luego KB5062170.
• Reforzar las prácticas de validación en entornos de preproducción, de modo que los parches se prueben primero en VMs de laboratorio que reproduzcan la arquitectura de AVD, Citrix o Hyper-V antes de desplegarlos masivamente.

Máquinas virtuales Linux: kernels que no arrancan tras actualizar

No todo son problemas de Windows. En sistemas Linux también es frecuente que, tras una actualización de distribución o un “apt upgrade” completo, el nuevo kernel no llegue a iniciar correctamente mientras que un kernel anterior funciona sin problemas. Un ejemplo típico sucede al actualizar Linux Mint (por ejemplo, de Mint a Una):

Después de la actualización general y un reinicio, la VM muestra un error de arranque indicando que hay un problema con el proceso de inicio (init) y sugiere “pasar la opción init= al kernel”. Si desde el menú de “Opciones avanzadas” del gestor de arranque se selecciona un kernel anterior (por ejemplo 5.4.0-91-generic) la VM arranca bien, pero con el kernel “nuevo” (por ejemplo 5.4.0-94-generic) ni siquiera el modo recuperación funciona.

En estos casos, las opciones más sencillas para un usuario poco experto pasan por:

• Seguir utilizando el kernel anterior que sí arranca, mientras se investiga o llega una corrección.
• Reinstalar el kernel problemático o probar otra versión disponible en los repositorios.
• Reinstalar el sistema operativo si la VM no contiene datos críticos y la complejidad de la reparación supera el tiempo que se tardaría en recomponer el entorno.

La mención a “pasar la opción init= al kernel” se refiere a modificar la línea de arranque del kernel (por ejemplo, editando la entrada en GRUB) para indicar explícitamente qué programa debe ejecutarse como proceso de inicio, pero para la mayoría de usuarios domésticos o de laboratorio suele ser más práctico optar por kernels estables o reinstalar.

Restauraciones de VMs VMware que no arrancan y ajustes de BIOS/UEFI

En entornos de backup de VMware, como NAKIVO Backup & Replication, puede ocurrir que una máquina virtual restaurada no arranque aunque el backup parezca correcto. Hay dos causas principales documentadas:

1. Windows clasifica el servidor como máquina Hyper-V: si la VM restaurada ejecuta Windows Server y el host ESXi de destino es 7 o anterior, el sistema puede haber detectado previamente el rol Hyper-V, lo que complica la virtualización anidada o genera incompatibilidades en el arranque.

2. Pérdida o modificación de los ajustes de arranque en el archivo .nvram: la configuración de la BIOS/UEFI de la VM, incluida la secuencia de inicio y las entradas de gestores de arranque (como grub.efi), se almacena en el fichero .nvram, que muchos productos de backup no incluyen en las copias. Si al restaurar la máquina se recrea ese fichero con valores por defecto, puede que ya no exista ninguna entrada válida para arrancar el sistema operativo.

Para el caso de la clasificación como Hyper-V, la solución propuesta es bastante directa: iniciar sesión en la VM original con PowerShell como administrador y ejecutar el comando:

Remove-WindowsFeature -Name Hyper-V

Después de eliminar completamente el rol de Hyper-V, se reinicia la VM, se lanza de nuevo el job de backup y posteriormente el job de recuperación. La VM restaurada, al no contener el rol Hyper-V, debería arrancar sin esos conflictos.

En cuanto a los ajustes de inicio perdidos, hay que entrar manualmente en el gestor de arranque EFI de la VM:

• Encender la VM y pulsar F2 en cuanto aparezca la pantalla de BIOS, o bien usar la opción “Power on to Firmware” desde VMware Workstation o vSphere.
• En el gestor de arranque EFI, ir a “Enter setup” → “Configure boot options”.
• Añadir las opciones de inicio necesarias mediante “Add boot option”, navegando hasta el gestor de arranque correcto (por ejemplo, grub.efi en EFI/<SO invitado>/) y dándole una descripción.
• Una vez creadas las entradas adecuadas, usar “Change boot order” para colocarlas en la parte superior de la lista.
• Confirmar los cambios y salir del gestor de mantenimiento de arranque, y después intentar de nuevo el arranque normal de la VM.

Con estos pasos, se consigue reconstruir una configuración de arranque funcional aunque el .nvram restaurado sea genérico, devolviendo a la máquina la capacidad de localizar y lanzar el gestor de arranque correcto.

Diagnóstico y supervisión en Citrix, AVD y otros entornos de escritorios virtuales

Cuando los problemas de arranque de VMs se producen en entornos de escritorios virtuales (Citrix Virtual Apps and Desktops, Azure Virtual Desktop, PC en la nube con Windows 365, etc.), la parte de plataforma cobra aún más importancia porque intervienen capas de broker, agentes VDA y herramientas de monitorización.

En Citrix, por ejemplo, la vista de Filtros > Máquinas de la consola de Supervisar ofrece información muy valiosa:

• Lista de máquinas configuradas en el sitio, tanto de sesión única como multisesión.
• Índice de patrón de carga en las máquinas multisesión, que ayuda a entender la distribución de sesiones y el rendimiento.
• Columna de Motivo del fallo, donde se detalla la causa de errores en el registro de VDA, fallos de inicio de sesión o problemas de redirección de zonas horarias, junto con acciones recomendadas.

Además, la página de Detalles de la máquina muestra datos clave sobre la infraestructura donde corre la VM, los parches rápidos aplicados, las opciones de Control de energía y el estado de licencias RDS, así como métricas de utilización de CPU, memoria, disco y GPU en tiempo real e histórico.

Cuando una VM no arranca o se comporta de forma inestable tras un parche, conviene revisar:

• Opciones de Control de energía: encendido, apagado, reinicio, forzar reinicio, etc., accesibles desde los filtros de Sesiones o Máquinas. Esto permite realizar acciones de potencia de forma centralizada y comprobar si el fallo es recurrente.
• Impacto en el rendimiento: mediante los gráficos de Utilización de máquinas (CPU, memoria, disco, GPU). Una latencia de disco excesiva o picos de IOPS pueden revelar que el problema viene de la capa de almacenamiento más que del parche en sí.
• Estado de licencias RDS de Microsoft: errores en la configuración de licencias pueden bloquear nuevas sesiones, aunque el sistema arranque correctamente; es importante distinguir entre fallo de arranque de la VM y bloqueo de conexiones RDS.
• Métricas de dispositivos de destino PVS (si usas Citrix Provisioning): uso de ancho de banda de NIC, reconexiones al servidor, reintentos UDP, tiempo de arranque, tipo de caché de escritura, tamaño de caché de RAM, etc., que ayudan a detectar cuellos de botella de red o almacenamiento que dificultan el inicio.

También es útil la capacidad de acceder a la consola de la máquina directamente desde Supervisor (para VMs alojadas en XenServer 7.3 o posterior), usando noVNC en el navegador. De esta manera puedes ver exactamente en qué punto se queda el arranque sin tener que abrir XenCenter ni otras consolas externas, siempre que tu navegador permita ventanas emergentes y tengas certificados SSL apropiados.

Por último, herramientas como Citrix Health Assistant pueden automatizar comprobaciones de registro de VDA, inicio de sesión y configuración de redirección, identificando causas probables de problemas técnicos que a veces se confunden con fallos de arranque cuando, en realidad, el sistema sí ha iniciado pero la sesión del usuario no.

En todos estos contextos, combinar la información de los mensajes de error del sistema operativo con los datos de la plataforma de virtualización y las herramientas de monitorización es lo que permite discernir si el origen del problema está en un parche conflictivo, en Secure Boot, en la red, en el almacenamiento o en un simple mal ajuste de BIOS/UEFI.

Cuando se domina este enfoque por capas (hipervisor, firmware, sistema operativo, agente, broker y usuario), los fallos de arranque de máquinas virtuales o AVD después de un parche dejan de ser un “apagón total” y pasan a ser incidencias que se pueden atacar con método, herramientas específicas y, sobre todo, buenas prácticas de pruebas previas y gestión de actualizaciones.