Problema

Al migrar máquinas virtuales Windows desde entornos basados en Xen (XCP‑ng, XenServer) a Proxmox VE, es frecuente que el arranque falle con una pantalla azul (BSOD). El síntoma típico es un reinicio inmediato o un mensaje de error que menciona controladores de hardware inexistentes o fallos de acceso a dispositivos. El problema no se limita a una versión concreta de Windows; cualquier invitado que haya sido creado con controladores PV de Xen y luego se ejecute bajo KVM/Proxmox puede presentar el mismo comportamiento.

Causa

1. Controladores y servicios de Xen persistentes

Durante la instalación en Xen, el SO carga módulos como xenblk, xenbus, xeniface, xenvbd y servicios asociados. Al iniciar bajo KVM, esos módulos no existen y el kernel de Windows intenta acceder a ellos, provocando una excepción de nivel crítico.

2. Controlador de disco virtual incorrecto

Xen expone discos como PV (paravirtual). Proxmox, por defecto, usa VirtIO‑SCSI o VirtIO‑Block. Si el registro sigue apuntando a un controlador PV, el subsistema de almacenamiento falla antes de que el kernel pueda montar la unidad del sistema.

3. Entradas de arranque (boot configuration) que hacen referencia a dispositivos Xen

El BCD (Boot Configuration Data) puede contener parámetros como device= xenblk0 o bootpath=\Device\XenDisk. Cuando el hipervisor cambia, el BCD sigue intentando arrancar desde un dispositivo inexistente.

4. Dependencias de servicios críticos

Algunos servicios de Windows (por ejemplo, XenServer Tools, XenPVDrivers) están configurados para iniciarse temprano. Si fallan, el Service Control Manager puede detener el arranque completo.

5. Cambios de controlador de red y de pantalla

Los adaptadores de red XenNet y los controladores de pantalla XenPV pueden quedar registrados como “primarios”. Proxmox usa VirtIO‑Net y QXL/SPICE; la falta de coincidencia genera errores de tiempo de arranque.

Solución

Paso 1 – Arrancar en WinRE y montar el registro offline

  1. Inicia la VM con un ISO de Windows Recovery Environment (WinPE/WinRE).
  2. Selecciona Troubleshoot → Advanced options → Command Prompt.
  3. Identifica la partición del sistema (normalmente C:) con diskpart → list volume.
  4. Monta el registro:
reg load HKLM\OfflineSystem X:\Windows\System32\config\SYSTEM
reg load HKLM\OfflineSoftware X:\Windows\System32\config\SOFTWARE

Paso 2 – Eliminar o deshabilitar controladores Xen

Los controladores aparecen bajo la clave HKLM\OfflineSystem\CurrentControlSet\Services. Los nombres típicos son xenblk, xenbus, xeniface, xenvbd, xenfilt. Para cada uno, cambia el valor Start a 4 (disabled) o elimínalo:

reg add "HKLM\OfflineSystem\CurrentControlSet\Services\xenblk" /v Start /t REG_DWORD /d 4 /f
reg add "HKLM\OfflineSystem\CurrentControlSet\Services\xenbus" /v Start /t REG_DWORD /d 4 /f

Si prefieres borrar la entrada:

reg delete "HKLM\OfflineSystem\CurrentControlSet\Services\xenblk" /f

Repite para cada controlador sospechoso.

Paso 3 – Ajustar el controlador de disco

  1. Cambia el controlador del disco a VirtIO‑SCSI o VirtIO‑Block en la configuración de la VM.
  2. En el registro, elimina la referencia al controlador PV:
reg delete "HKLM\OfflineSystem\CurrentControlSet\Services\storport\Parameters\Device" /v XenDisk /f
  1. Asegúrate de que la clave HKLM\OfflineSystem\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318} (Controladores de disco) no tenga valores UpperFilters o LowerFilters que apunten a xenblk.

Paso 4 – Reparar el BCD

Desmonta los registros y arranca de nuevo en WinRE:

reg unload HKLM\OfflineSystem
reg unload HKLM\OfflineSoftware

Luego, desde la línea de comandos de WinRE:

bcdboot X:\Windows /s X: /f ALL

Esto recrea el BCD apuntando a la partición correcta. Si el BCD sigue referenciando dispositivos Xen, usa:

bcdedit /enum all
bcdedit /deletevalue {default} device
bcdedit /deletevalue {default} osdevice
bcdedit /set {default} device partition=C:
bcdedit /set {default} osdevice partition=C:

Paso 5 – Instalar los drivers VirtIO adecuados

Una vez que la VM arranca, instala el VirtIO driver pack (ISO de Fedora o Proxmox). Prioriza:

  • viostor para discos
  • vioscsi si usas SCSI
  • netkvm o virtio-net para red
  • qxl o spice para pantalla (si se necesita)

Reinicia y verifica que el sistema arranca sin BSOD.

Paso 6 – Limpieza final

Si la VM sigue mostrando errores, revisa el visor de eventos (eventvwr.msc) para identificar controladores que intentan cargarse. Repite el proceso de deshabilitación para cualquier controlador adicional que aparezca.

Cuándo aplicar esta solución

  • Síntomas: BSOD inmediato al arrancar, mensajes de error que mencionan xenblk, xenbus, xenvbd, o “disk controller not found”.
  • Entorno: Migración de Windows (7/8/10/Server 2012‑2022) desde XCP‑ng/XenServer a Proxmox VE (KVM).
  • No aplica: Cuando la VM ya se ejecuta bajo Xen sin problemas, o cuando el error es claramente de hardware físico (RAM, CPU). En esos casos, la causa suele estar fuera del ámbito de los controladores Xen.

Código

# Montar registro offline
reg load HKLM\OfflineSystem X:\Windows\System32\config\SYSTEM
reg load HKLM\OfflineSoftware X:\Windows\System32\config\SOFTWARE

# Deshabilitar controladores Xen
for driver in xenblk xenbus xeniface xenvbd xenfilt; do
    reg add "HKLM\OfflineSystem\CurrentControlSet\Services\$driver" /v Start /t REG_DWORD /d 4 /f
done

# Reparar BCD
bcdboot X:\Windows /s X: /f ALL
bcdedit /deletevalue {default} device
bcdedit /deletevalue {default} osdevice
bcdedit /set {default} device partition=C:
bcdedit /set {default} osdevice partition=C:

# Desmontar registro
reg unload HKLM\OfflineSystem
reg unload HKLM\OfflineSoftware

Verificación

  1. Arranque limpio: La VM debe iniciar sin mostrar BSOD.
  2. Visor de eventos: Busca entradas bajo System con nivel Error que mencionen controladores faltantes.
  3. Device Manager: Confirma que los dispositivos de disco y red aparecen bajo los controladores VirtIO, sin símbolos de advertencia.
  4. Prueba de I/O: Copia un archivo grande dentro de la VM para validar el rendimiento del nuevo controlador de disco.

Notas adicionales

  • Backup del registro: Antes de manipular el registro offline, copia los archivos SYSTEM y SOFTWARE a otro directorio. Un error de escritura puede dejar la VM inarrancable.
  • Versiones de Windows: Windows 7 y Server 2008 R2 requieren el paquete de actualizaciones de Service Pack para cargar drivers VirtIO sin problemas.
  • Modo de arranque: Si la VM usa UEFI, el proceso de reparación del BCD cambia ligeramente; usa bcdboot X:\Windows /s Z: /f UEFI donde Z: es la partición EFI.
  • Herramientas de diagnóstico: winver y msinfo32 dentro de WinRE pueden ayudar a confirmar la arquitectura (x86 vs x64) y la versión del controlador cargado.
  • Automatización: En entornos con cientos de VMs, considera crear un script PowerShell que, ejecutado desde WinPE, recorra la lista de controladores Xen y los desactive automáticamente.

Con estos pasos, la mayoría de los BSOD relacionados con migraciones de Xen a Proxmox desaparecen, y la VM queda preparada para aprovechar los controladores VirtIO de alto rendimiento.