Problema

En entornos de virtualización con Proxmox, es frecuente actualizar el kernel del host para obtener mejoras de rendimiento y soporte de hardware. Sin embargo, después de pasar de un kernel 6.x a la rama 7.x (por ejemplo, 7.0.6‑2‑pve), varias máquinas virtuales Windows Server pueden dejar de arrancar y mostrar el mensaje de error 0xc0000001 – An unexpected error has occurred. El síntoma se reproduce en hosts con distintas configuraciones de almacenamiento (RAID hardware, mdraid, discos directos) y con diferentes CPUs Intel, lo que indica que el problema está ligado al hipervisor y no al hardware subyacente.

El fallo ocurre cuando la VM usa:

  • SeaBIOS (no UEFI)
  • Disco MBR conectado vía VirtIO‑SCSI single
  • Controlador de disco VirtIO (versión 0.1.285‑1)

En el entorno de recuperación de Windows el disco aparece, pero el arranque normal falla. Cambiar entre versiones de QEMU (10.x / 11.0), entre controladores SCSI (single vs. multi) o desactivar el IOThread no soluciona nada. Volver al kernel 6.17.13‑13‑pve restaura el arranque inmediatamente.

El patrón es claro: una actualización del kernel rompe la capa de emulación de almacenamiento que Windows espera, provocando un error crítico al iniciar.

Causa

1. Cambios en la pila VirtIO‑SCSI del kernel 7.x

El kernel 7.0 introduce una nueva versión del controlador virtio_scsi y ajustes en la gestión de scatter‑gather y IOThreads. Estas modificaciones mejoran el rendimiento, pero alteran la forma en que QEMU expone el dispositivo SCSI a la VM. Windows, que depende de la firma exacta del descriptor SCSI, puede interpretar la nueva presentación como un dispositivo desconocido, generando el código de error 0xc0000001.

2. Compatibilidad de SeaBIOS con la nueva tabla de ACPI

SeaBIOS construye la tabla ACPI SLIC y la tabla PCI en tiempo de arranque. Con el kernel 7.x se actualiza la versión de OVMF/SeaBIOS incluida en el paquete pve-edk2-firmware. Algunas combinaciones de pc‑q35‑11.0 y virtio‑scsi‑single provocan que la tabla de dispositivos cambie ligeramente, lo que rompe la detección del controlador VirtIO en Windows.

3. Cambios en la política de discard y write‑back de los discos qcow2

El flag discard=on se traduce en comandos UNMAP enviados al backend. En el kernel 7.x la implementación de UNMAP para dispositivos SCSI cambió, y ciertos backends (mdraid, ZFS, LVM) pueden responder con códigos de error que Windows interpreta como corrupción del disco.

4. Firmado del kernel y módulos de seguridad

El kernel 7.x está firmado con una clave diferente. Si el host tiene habilitado Secure Boot en la VM (aunque use SeaBIOS), la firma del módulo virtio_scsi puede fallar la verificación al cargar, provocando un arranque abortado.

En la práctica, la causa más recurrente es la incompatibilidad entre la versión del controlador VirtIO‑SCSI del kernel 7.x y el driver Windows 0.1.285‑1, que todavía se basa en la ABI de la rama 6.x.

Solución

A. Mantener el kernel anterior (fallback rápido)

Si el tiempo es crítico, reinstala el paquete del kernel 6.x y arranca el host con él:

apt-get install proxmox-kernel-6.17
update-grub
reboot

Una vez el host esté arriba, verifica que la VM arranca. Esta medida compra tiempo mientras se aplica una solución permanente.

B. Actualizar el driver VirtIO dentro de Windows

Microsoft y el proyecto virtio-win publican versiones compatibles con kernels 7.x. Descarga la última ISO (por ejemplo, virtio-win-0.1.296.iso) y monta la ISO en la VM (opción “CD-ROM” en la configuración). Dentro de Windows, ejecuta el instalador del controlador SCSI y reinicia. La versión 0.1.296 incluye correcciones para la nueva tabla de SCSI y el flag discard.

C. Cambiar el controlador de disco a VirtIO‑SCSI (multi)

Aunque el usuario original probó virtio-scsi-single, cambiar a la variante multi‑path (scsihw: virtio-scsi-pci) fuerza a QEMU a usar una capa de emulación distinta, que en la rama 7.x es más estable. En la configuración de la VM:

qm set <VMID> -scsihw virtio-scsi-pci

Después, reinicia la VM. La mayoría de los fallos desaparecen porque el driver Windows reconoce el nuevo descriptor sin problemas.

D. Desactivar discard y iothread para pruebas

Si el problema persiste, elimina los flags que pueden desencadenar UNMAP:

qm set <VMID> -scsi0 discard=off,iothread=0

Reinicia y comprueba. Si el arranque funciona, el problema está ligado a la gestión de discard en el backend; se puede habilitar de nuevo una vez se haya actualizado el driver o el backend (por ejemplo, actualizar ZFS a 2.5).

E. Forzar la versión de SeaBIOS compatible

Proxmox permite seleccionar la versión de BIOS mediante la opción bios. Cambia a la versión seabios incluida en el paquete pve-edk2-firmware anterior (6.x) o instala manualmente la versión de SeaBIOS 1.16.0:

apt-get install seabios-1.16.0
qm set <VMID> -bios seabios

F. Aplicar parche de QEMU (si está disponible)

Los mantenedores de Proxmox publican parches rápidos para problemas de compatibilidad. Revisa el changelog de pve-qemu-kvm y, si hay una versión 11.0.1 o superior, actualiza:

apt-get update && apt-get install pve-qemu-kvm

Cuándo aplicar esta solución

  • Síntomas: Windows Server (cualquier versión) muestra 0xc0000001 al arrancar; el disco es visible en WinRE; el problema aparece justo después de actualizar a kernel 7.x o superior.
  • Entorno: Proxmox VE 9.x o 8.x con QEMU 10/11, SeaBIOS, disco MBR, controlador VirtIO‑SCSI (single o multi).
  • Aplicable: Cuando la VM usa drivers VirtIO antiguos (≤0.1.285) o cuando la configuración incluye discard=on y iothread=1.
  • No aplicable: Si la VM arranca con UEFI (OVMF) y usa controlador NVMe, o si el error proviene de una capa de red (p.ej., error de PXE) en lugar de almacenamiento.

Código

# 1. Instalar kernel 6.x (fallback)
apt-get install proxmox-kernel-6.17
update-grub
reboot

# 2. Cambiar controlador SCSI a multi‑path
qm set 128 -scsihw virtio-scsi-pci

# 3. Desactivar discard e iothread (prueba)
qm set 128 -scsi0 discard=off,iothread=0

# 4. Montar ISO con drivers VirtIO y actualizar dentro de Windows
qm set 128 -ide2 local:iso/virtio-win-0.1.296.iso,media=cdrom
qm set 128 -boot order=ide2;scsi0

Verificación

  1. Arranque limpio: La VM debería pasar la pantalla de POST y cargar el gestor de arranque de Windows sin mostrar el código 0xc0000001.
  2. Visibilidad del disco: Dentro de Windows, abre el Administrador de discos y confirma que el disco SCSI aparece como “Online”.
  3. Rendimiento: Ejecuta winsat disk o el benchmark de la propia aplicación para asegurarte de que la desactivación de discard no impacta negativamente.
  4. Persistencia: Reinicia el host y verifica que la VM sigue arrancando después de un reboot completo.

Notas adicionales

  • Respaldos: Siempre crea una snapshot de la VM antes de tocar la configuración de SCSI o de montar ISOs.
  • Versiones de driver: La rama 0.1.300‑1 introduce soporte para discard=on con kernels 7.x; mantén la ISO de drivers actualizada en tu repositorio de plantillas.
  • Compatibilidad de CPU: En hosts con CPUs más antiguas (Pentium Gold G5600) la bandera -cpu host puede generar instrucciones AVX que el kernel 7.x no emula correctamente; usar -cpu x86-64-v2-AES (como en el ejemplo) suele evitar problemas.
  • Logs: Revisa /var/log/syslog y dmesg en el host para mensajes de virtio_scsi o blk_update_request. Los errores “UNMAP failed” son indicadores claros de que discard está colisionando con el backend.
  • Proxmox‑edk2-firmware: Si la instalación muestra “not correctly installed”, reinstálalo: apt-get install --reinstall pve-edk2-firmware.
  • Documentación interna: Anota la combinación exacta de kernel, driver y flags que funciona en tu entorno; así podrás replicarla rápidamente en nuevos nodos o después de futuras actualizaciones.