Proxmox: Windows no detecta el disco — instala correctamente los controladores VirtIO

noviembre 25, 2025 • febrero 3, 2026 • Lectura: 24 min • Views: 12

¿Te fue útil?

El instalador de Windows está en marcha, la VM arranca bien desde el ISO y luego: “¿Dónde desea instalar Windows?” muestra una lista vacía. O tu VM Windows ya instalada de repente informa que no hay dispositivo de arranque después de que “solo” cambiaste a VirtIO porque alguien dijo que era más rápido. Aquí es cuando la gente suele entrar en pánico, reiniciar tres veces y empezar a culpar a ZFS, a la controladora RAID o a la luna.

La verdad suele ser aburrida: Windows no puede comunicarse con el controlador de almacenamiento virtual que presentaste. Lo solucionas presentando el controlador correcto e instalando el controlador VirtIO adecuado en el momento correcto, en el entorno Windows correcto (Setup frente a sistema instalado). Hazlo de forma limpia y obtendrás almacenamiento rápido, menos interrupciones extrañas y comportamiento predecible bajo carga.

Guía rápida de diagnóstico

Si quieres el 80/20, aquí está. Ejecuta esto de arriba hacia abajo. Detente tan pronto como encuentres la incongruencia.

Primero: ¿estás en Windows Setup o dentro de un Windows ya instalado?

Windows Setup (instalador): debes hacer clic en “Cargar controlador” y apuntar al ISO de VirtIO, o usar temporalmente un controlador que Windows ya reconozca (SATA).
Windows ya instalado: necesitas tener instalados los controladores VirtIO antes de cambiar el disco/controlador, o corres el riesgo de INACCESSIBLE_BOOT_DEVICE.

Segundo: ¿qué controlador elegiste en Proxmox?

VirtIO SCSI (recomendado) usando virtio-scsi-single en Proxmox: requiere el controlador vioscsi.
VirtIO Block: requiere el controlador viostor.
SATA: Windows lo ve sin controladores VirtIO; es más lento y menos “cloud-native”, pero ideal como arranque temporal.

Tercero: ¿está montado el ISO de VirtIO y es visible para la VM?

Monta virtio-win.iso como una segunda unidad de CD/DVD en Proxmox.
En “Cargar controlador” del Setup, navega a la carpeta correcta para tu versión de Windows (usualmente \vioscsi\w11\amd64, \vioscsi\w10\amd64 o equivalentes de Server).

Cuarto: problemas con Secure Boot y firma de controladores

Windows 11 + Secure Boot: los controladores VirtIO actuales están firmados, pero los ISOs antiguos pueden darte problemas. Usa un ISO VirtIO reciente y evita “el ISO que encontraste en una carpeta polvorienta”.
Si usas UEFI/OVMF, mantenlo consistente. Cambiar el tipo de BIOS a mitad de camino altera la mecánica de arranque.

Quinto: confirma que Proxmox realmente está presentando un disco

Sí, suena obvio. Aún así comprueba la configuración de la VM y el estado del almacenamiento en Proxmox. Un volumen faltante o bloqueado se ve exactamente como “sin disco” desde la perspectiva del invitado.

Broma #1: El instalador de Windows es como un portero: si tu controlador de almacenamiento no está en la lista, tu disco no entra.

Datos y contexto interesantes (por qué esto sigue ocurriendo)

VirtIO nació como una optimización en la era KVM/QEMU: es un modelo de dispositivo paravirtualizado diseñado para evitar la sobrecarga de emulación pesada.
Windows no incluye controladores de almacenamiento VirtIO por defecto, por eso en Linux “simplemente funciona” y en Windows no.
IDE sigue existiendo principalmente por compatibilidad: es lento, limitado y útil sobre todo para arrancar instaladores antiguos o como bus de CD-ROM de reserva.
VirtIO SCSI existe porque “una interfaz para dominarlos a todos” no fue suficiente: proporciona una abstracción SCSI sobre VirtIO y soporta características como TRIM/UNMAP en pilas virtualizadas cuando se configura correctamente.
“VirtIO Block” vs “VirtIO SCSI” no es solo un nombre: tienen controladores distintos en Windows (viostor vs vioscsi) y diferentes comportamientos operativos bajo ciertas cargas.
Los controladores integrados de Microsoft priorizan compatibilidad amplia, por eso SATA/AHCI funciona en todas partes y VirtIO no.
Windows Setup es su propio pequeño entorno OS: cargar un controlador en Setup no implica automáticamente que tu Windows instalado lo tenga preparado correctamente (y viceversa).
Los cambios de controlador son cambios críticos de arranque en Windows: los controladores de almacenamiento deben estar presentes y configurados para iniciarse pronto, o tendrás fallos de arranque.
Los valores por defecto de Proxmox han mejorado con el tiempo, pero muchos artículos siguen recomendaciones antiguas (como usar modelos legacy o ajustes de BIOS extraños).

Qué significa realmente “no ve el disco” en Proxmox

“Windows no ve el disco” es un síntoma. En el fondo, sucede una de estas cosas:

No hay disco realmente adjunto (problema de configuración de VM, problema de almacenamiento, ID de VM equivocado, volumen borrado, volumen bloqueado o el disco está conectado en un bus desde el que tu firmware no arranca).
Hay un disco adjunto, pero Windows no tiene controlador para el controlador (situación clásica de VirtIO durante Setup).
Hay disco y controlador, pero Windows no puede usarlo aún (controlador no cargado en WinPE/Setup, carpeta de arquitectura incorrecta, problema de firma del controlador).
El disco es visible pero no usable (política de disco offline, desajuste GPT/MBR según configuración de arranque, Storage Spaces raro o metadatos obsoletos).
El disco es visible pero el rendimiento es catastrófico (modo de caché incorrecto, sin I/O thread, desajuste de configuración de QEMU o saturación del almacenamiento host).

Así que el plan es sencillo: demuestra qué está presentando Proxmox, demuestra qué está cargando Windows y luego únelo todo con el paquete VirtIO correcto.

Elige el modelo de almacenamiento virtual correcto (y deja de improvisar)

Esto es lo que recomiendo para la mayoría de VMs Windows de producción en Proxmox:

Bus/controlador: VirtIO SCSI con virtio-scsi-single (GUI de Proxmox: SCSI Controller → “VirtIO SCSI single”).
Tipo de disco: Disco SCSI (por ejemplo, scsi0).
Caché: Normalmente “Write back” solo si entiendes el riesgo; de lo contrario el valor por defecto “None” suele ser el más seguro. Si usas ZFS, ten especial cuidado con la doble caché y las semánticas de fallo.
IO thread: Habilita I/O thread para discos con mucha actividad. Suele reducir picos de latencia bajo carga mixta.
Trim/Discard: Habilita discard para almacenamiento thin-provisioned o pools con SSD cuando quieras reclamación de espacio (y hayas verificado que el almacenamiento subyacente lo soporta sensatamente).

¿Cuándo no elegiría VirtIO SCSI?

Arranque del instalador: Si no quieres molestarte en cargar controladores durante Setup, usa SATA para la instalación y cambia después (pero hazlo de forma segura).
Versiones muy antiguas de Windows: Existe soporte de controladores, pero el riesgo operativo aumenta. Si usas algo lo bastante viejo para ser “legacy”, ya estás tomando decisiones.

VirtIO Block puede estar bien, pero VirtIO SCSI suele ser la opción “buena por defecto” en Proxmox porque funciona mejor con múltiples discos, colas y patrones operativos comunes.

Instalación nueva: carga controladores VirtIO durante Windows Setup

Este es el camino más limpio: presenta un disco respaldado por VirtIO desde el inicio, luego carga el controlador en Setup para que Windows lo vea e instale correctamente.

Paso 1: Adjunta ambos ISOs

Monta tu ISO de Windows como CD/DVD 1. Monta virtio-win.iso como CD/DVD 2. Si solo montas VirtIO y olvidas Windows, tendrás un momento tranquilo para reflexionar sobre tus decisiones de vida.

Paso 2: Usa VirtIO SCSI single y un disco SCSI

En Hardware de la VM en Proxmox:

Controlador SCSI: VirtIO SCSI single
Disco duro: SCSI (scsi0)

Paso 3: En Windows Setup, haz clic en “Cargar controlador”

Cuando llegues a la selección de disco y no veas nada:

Haz clic en Cargar controlador.
Navega hasta la unidad de CD del VirtIO.
Elige la carpeta del controlador que coincida con tu SO y arquitectura. Ejemplos:
- \vioscsi\w11\amd64
- \vioscsi\w10\amd64
- \vioscsi\2k22\amd64 (para Windows Server 2022)
Selecciona el controlador y continúa. Tu disco debería aparecer.

Paso 4: Instala controladores VirtIO adicionales después del primer arranque

El almacenamiento es el elemento crítico, pero no te quedes ahí. Instala:

Red (NetKVM) si usaste una NIC VirtIO
Balloon si usas conceptos de memoria dinámica (algunos sí, otros no)
QEMU Guest Agent para apagados limpios, reporte de IP y mejor orquestación

VM Windows existente: mover de SATA/IDE a VirtIO/Scsi de forma segura

Aquí es donde la gente rompe cosas. El modo de fallo es predecible: Windows arranca bien en SATA, cambias el disco a VirtIO SCSI, Windows hace pantalla azul con INACCESSIBLE_BOOT_DEVICE porque el controlador crítico de arranque no está instalado/activo.

El enfoque seguro es igualmente predecible: haz que Windows aprenda el nuevo controlador mientras todavía arranca con el viejo.

Método A (recomendado): añade un segundo disco VirtIO, instala controladores y luego migra

Mantén tu disco de arranque actual en SATA (o lo que funcione ahora).
Añade un segundo disco en VirtIO SCSI (scsi1) o VirtIO Block, según lo que planees usar.
Arranca Windows. Detectará el nuevo hardware y puedes indicarle los controladores VirtIO (o instalar el paquete VirtIO).
Confirma que el controlador está instalado y que el nuevo disco es visible en Administración de discos.
Entonces migra el disco de arranque/controlador o clona los datos según necesites.

Método B: prepara el controlador y cambia el controlador (rápido, más arriesgado)

Si debes hacerlo de una sola vez:

Monta el ISO VirtIO en la VM.
Instala el paquete de controladores VirtIO dentro de Windows.
Apaga, cambia el bus/controlador del disco en Proxmox, arranca y reza un poco menos de lo habitual.

Esto suele funcionar a menudo. “A menudo” no es una estrategia de fiabilidad. Usa el Método A cuando seas responsable del tiempo de actividad.

Broma #2: Cambiar controladores de almacenamiento de Windows sin preparar los controladores es como cambiar el volante de un coche a velocidad de autopista: técnicamente posible, socialmente desaconsejado.

Tareas prácticas con comandos (y decisiones)

Estas son tareas operativas reales que puedes ejecutar en el host Proxmox. Cada una incluye qué te dice la salida y qué decisión tomar a continuación. Si las haces en orden, normalmente resolverás el problema antes de que tu café se enfríe.

Task 1: Confirmar la configuración de hardware de la VM (¿qué bus de disco presentaste realmente?)

cr0x@server:~$ qm config 104
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: win11-prod
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0
scsihw: virtio-scsi-single
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Qué significa: Esta VM usa VirtIO SCSI single y el disco de arranque está en scsi0. Windows Setup necesitará vioscsi.

Decisión: Si el disco es virtio0, planea cargar viostor en su lugar. Si el disco es sata0, no deberías necesitar controladores VirtIO para verlo.

Task 2: Confirmar que el volumen de disco existe en el almacenamiento de Proxmox

cr0x@server:~$ pvesm list rpool | grep vm-104-disk-0
rpool:vm-104-disk-0  raw  128849018880  0

Qué significa: El volumen existe y es visible para Proxmox.

Decisión: Si falta, no estás ante un problema de controladores VirtIO: estás ante un problema de mapeo de almacenamiento, borrado o ID de VM equivocado.

Task 3: Comprobar si un snapshot de backup o un bloqueo está bloqueando operaciones del disco

cr0x@server:~$ qm status 104
status: stopped

Qué significa: La VM está apagada; no se indica un bloqueo activo aquí.

Decisión: Si ves un bloqueo en la GUI o en el log de tareas, despeja la causa raíz antes de esperar una conexión de disco consistente.

Task 4: Verificar que el ISO VirtIO está presente en el host

cr0x@server:~$ ls -lh /var/lib/vz/template/iso/virtio-win.iso
-rw-r--r-- 1 root root 705M Dec  2 11:40 /var/lib/vz/template/iso/virtio-win.iso

Qué significa: El ISO existe en el almacenamiento local en la ruta estándar de ISOs de Proxmox.

Decisión: Si falta, súbelo correctamente; no montes un archivo aleatorio y lo des por bueno.

Task 5: Confirmar que la VM está montando realmente el ISO VirtIO como CD-ROM

cr0x@server:~$ qm config 104 | egrep 'ide2|ide3|sata2'
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Qué significa: El ISO VirtIO está adjunto como un dispositivo CD-ROM.

Decisión: Si no está adjunto, Windows Setup nunca encontrará el controlador. Adjústalo, reinicia la VM en Setup y prueba de nuevo.

Task 6: Comprobar parámetros del proceso QEMU para la VM (¿aplicó Proxmox lo que crees?)

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 104' | head -n 1
root     22188     1 12 11:52 ?        00:01:44 /usr/bin/kvm -id 104 -name win11-prod -machine type=pc-q35-8.1 ... -device virtio-scsi-pci,id=scsihw0 ...

Qué significa: QEMU está ejecutándose con un dispositivo VirtIO SCSI.

Decisión: Si esperabas SATA pero ves dispositivos VirtIO, tu configuración no es la que crees: corrige la incongruencia antes de tocar Windows.

Task 7: Revisar logs del kernel del host por errores de disco/almacenamiento alrededor del arranque de la VM

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'zfs|scsi|blk|i/o error|qemu' | tail -n 15
Dec 26 11:51:10 server kernel: zfs: spa_sync: doing sync pass
Dec 26 11:51:12 server kernel: blk_update_request: I/O error, dev zd16, sector 123456 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 11:51:12 server kernel: Buffer I/O error on dev zd16, logical block 15432, async page read

Qué significa: El host está arrojando errores de I/O. Esto puede aparecer en el invitado como “sin disco” o instalaciones corruptas.

Decisión: Deja de culpar a los controladores VirtIO e investiga primero la salud del almacenamiento host (estado del pool, discos subyacentes, problemas del controlador) antes de continuar.

Task 8: Comprobar la salud del pool ZFS (si usas ZFS)

cr0x@server:~$ zpool status -x
all pools are healthy

Qué significa: No hay problemas conocidos en ZFS.

Decisión: Si reporta degraded/faulted, arregla eso primero. El fallo de Setup de Windows en ver un disco no siempre es un problema de controladores.

Task 9: Confirmar el modo de firmware/arranque de la VM (UEFI vs SeaBIOS)

cr0x@server:~$ qm config 104 | egrep 'bios|efidisk0|machine'
bios: ovmf
efidisk0: rpool:vm-104-disk-1,size=4M
machine: q35

Qué significa: La VM usa UEFI (OVMF) con un disco EFI y máquina tipo Q35.

Decisión: Mantenlo consistente. Si instalaste Windows en UEFI, no cambies a SeaBIOS más tarde a menos que disfrutes de la arqueología de cargadores de arranque.

Task 10: Validar el modelo de NIC (porque necesitarás red más tarde para terminar la configuración)

cr0x@server:~$ qm config 104 | grep '^net0'
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0

Qué significa: Se usa una NIC VirtIO. Windows Setup puede no tener controlador de red tampoco.

Decisión: Si necesitas red durante Setup (para unir al dominio, controladores, actualizaciones), prepárate para cargar NetKVM desde el ISO VirtIO también — o usa temporalmente una NIC emulada Intel E1000.

Task 11: Comprobar logs de tareas de Proxmox por cambios de hardware recientes

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/index
UPID:server:00005A1C:0002A9F4:676D8B6E:qmset:104:root@pam:
UPID:server:00005A9F:0002B0A1:676D8BAA:qmstart:104:root@pam:
UPID:server:00005B10:0002B733:676D8BE2:qmstop:104:root@pam:

Qué significa: Alguien cambió la configuración de la VM y la inició/detuvo.

Decisión: Si el bus/controlador del disco se cambió recientemente, asume primero un desajuste de controladores. Vuelve atrás o aplica el procedimiento de migración correcto.

Task 12: Inspeccionar las líneas efectivas de mapeo de disco (SCSI vs VirtIO vs SATA)

cr0x@server:~$ qm config 104 | egrep '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Qué significa: El único disco duro es respaldado por VirtIO SCSI (scsi0). Si Windows no lo ve, te falta vioscsi en Setup.

Decisión: No cambies cinco cosas a la vez. Arregla la carga del controlador primero.

Task 13: Si sospechas un bug de “disco no adjunto”, compara la configuración en ejecución vs archivos de disco en el almacenamiento

cr0x@server:~$ ls -lh /rpool/images/104/
total 121G
-rw-r----- 1 root root 120G Dec 26 11:50 vm-104-disk-0
-rw-r----- 1 root root 4.0M Dec 26 11:45 vm-104-disk-1

Qué significa: Los archivos de disco existen donde se espera (ejemplo para un montaje tipo directorio de dataset ZFS). Tu mapeo en Proxmox probablemente está bien.

Decisión: Si falta el archivo de disco, no sigas reinstalando Windows. Restaura desde copia de seguridad o arregla el mapeo de almacenamiento.

Task 14: Comprobar flags de virtualización de CPU del host y salud de KVM (anormal, pero elimina una clase de rarezas)

cr0x@server:~$ egrep -m 1 '(vmx|svm)' /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ...

Qué significa: Están presentes las extensiones de virtualización hardware.

Decisión: Si KVM está mal configurado, verás problemas más amplios en las VMs, no solo “sin disco”. Esto es una comprobación de sanidad, no tu sospecha principal.

Errores comunes: síntoma → causa raíz → solución

Esta sección es lo que consume horas en entornos reales porque todos asumen la capa equivocada.

1) Síntoma: Windows Setup no muestra discos en absoluto

Causa raíz: Se presentó un controlador de almacenamiento VirtIO, pero no se cargó el controlador VirtIO en Setup.
Solución: Monta el ISO VirtIO, haz clic en “Cargar controlador”, elige vioscsi para VirtIO SCSI o viostor para VirtIO Block, coincidiendo con tu versión de Windows y amd64.

2) Síntoma: “No se encontraron controladores de dispositivo” al examinar el ISO VirtIO

Causa raíz: Carpeta equivocada (versión de SO incorrecta), arquitectura equivocada, o estás usando VirtIO Block pero examinas vioscsi (o viceversa).
Solución: Revisa el bus de disco en Proxmox. Luego selecciona la ruta de controlador correcta. Si hay duda: VirtIO SCSI → \vioscsi\...\amd64; VirtIO Block → \viostor\...\amd64.

3) Síntoma: VM Windows existente hace pantalla azul con INACCESSIBLE_BOOT_DEVICE después de cambiar el controlador

Causa raíz: El controlador de almacenamiento no estaba instalado/configurado para iniciarse antes del cambio de controlador.
Solución: Vuelve al controlador antiguo para arrancar. Luego prepara los controladores usando el método “añadir segundo disco VirtIO”. Solo entonces cambia el bus del disco de arranque.

4) Síntoma: El disco aparece en Setup tras cargar el controlador, pero la instalación falla o se corrompe después

Causa raíz: Inestabilidad del almacenamiento host, errores de I/O o modo de caché inseguro ante pérdida de energía.
Solución: Revisa logs del host y salud del pool. Usa caché conservadora hasta que puedas probar la durabilidad de extremo a extremo (y tengas un SAI y las semánticas de write barriers correctas en tu pila).

5) Síntoma: Windows se instala, pero no hay red durante el setup o tras el primer arranque

Causa raíz: Se seleccionó NIC VirtIO pero no se instaló NetKVM.
Solución: Carga el controlador NetKVM desde el ISO VirtIO durante Setup, o usa temporalmente una NIC emulada para conectarte y luego instala el paquete VirtIO.

6) Síntoma: Windows ve el disco, pero el rendimiento es pésimo (alta latencia, pocas IOPS)

Causa raíz: Ajustes de disco incorrectos (sin iothread, modo de caché subóptimo), contención en el host o backend de almacenamiento saturado.
Solución: Habilita iothread para discos con mucha actividad, revisa el modo de caché con cuidado y mide la latencia del almacenamiento host. No “optimices” a ciegas.

7) Síntoma: Tras instalar el controlador, Windows sigue sin ver el disco hasta reiniciar

Causa raíz: El controlador se instaló pero la enumeración del dispositivo no se ha refrescado en el entorno.
Solución: En Setup, vuelve a escanear o retrocede/avanza. En Windows instalado, reescanear discos en Administración de discos o reiniciar. Es normal; no te precipites.

Listas de verificación / plan paso a paso

Lista A: Instalación nueva de Windows en VirtIO SCSI (ruta recomendada)

Crea la VM con UEFI (OVMF) si quieres los valores modernos de Windows; mantén el tipo de máquina Q35 consistente.
Configura el SCSI Controller a VirtIO SCSI single.
Añade disco como SCSI (scsi0); habilita iothread si esperas I/O sostenido; considera discard si está thin-provisioned/SSD-backed.
Monta el ISO de Windows como CD-ROM.
Monta el ISO VirtIO como segundo CD-ROM.
Arranca el ISO de Windows, llega a la selección de disco y haz clic en “Cargar controlador”.
Carga el controlador vioscsi que coincida con la versión de SO y amd64.
Confirma que el disco aparece; instala Windows.
Después del primer arranque, instala el paquete completo VirtIO (storage, net, balloon, qemu-ga) desde el ISO VirtIO.
Reinicia y valida que el Administrador de dispositivos no muestre dispositivos desconocidos para almacenamiento/red.

Lista B: Convertir una VM Windows existente de SATA a VirtIO SCSI sin drama

Haz snapshot o copia de seguridad de la VM. Esto no es opcional si te pagan por ser responsable.
Monta el ISO VirtIO en la VM existente.
Añade un disco de prueba pequeño como SCSI bajo VirtIO SCSI single (scsi1) manteniendo el disco de arranque sin cambios.
Arranca Windows; instala los controladores VirtIO (o el paquete VirtIO). Confirma que Windows detecta el nuevo disco y controlador.
Apaga la VM limpiamente.
Cambia el bus/controlador del disco de arranque a SCSI (VirtIO SCSI single).
Arranca y verifica que Windows inicia sin pantallas azules relacionadas con almacenamiento.
Quita el disco de prueba si solo fue para preparar controladores.

Lista C: Si estás atascado a mitad de la instalación y necesitas una solución táctica

Cambia temporalmente el disco de arranque a SATA (AHCI) para que Windows Setup lo vea sin controladores.
Instala Windows.
Dentro de Windows, instala los controladores VirtIO desde el ISO VirtIO.
Usa el Método A para migrar a VirtIO SCSI más tarde.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición equivocada

La organización tenía una “plantilla dorada” estándar para VMs Windows. Alguien la construyó hace meses usando discos SATA porque “funcionaba en todas partes”. Con el tiempo, el equipo de virtualización modernizó todo lo demás: Q35, UEFI, NICs VirtIO. El almacenamiento quedó en SATA porque nadie quería tocarlo. Luego llegó un ingeniero nuevo y hizo lo que hacen los nuevos ingenieros: “arreglar” aquello que se ve obviamente subóptimo.

Migraron varias VMs de SATA a VirtIO SCSI, una tras otra, durante una ventana de mantenimiento. Asumieron que Windows detectaría el controlador al arrancar e instalaría los controladores automáticamente, porque eso es lo que Linux hace. La primera VM hizo pantalla azul. La segunda VM también. En ese punto, la ventana se convirtió en un simulacro de incendio y el canal de mantenimiento empezó a llenarse de lenguaje creativo.

La causa raíz no fue exótica. No se preparó el controlador VirtIO como controlador de arranque. Windows no tenía forma de hablar con el disco de arranque, así que no pudo cargar el OS para instalar el controlador necesario para hablar con el disco necesario para cargar el OS. Es un perfecto pequeño círculo del doom.

La recuperación fue sencilla una vez que alguien respiró: volver a SATA para arrancar, montar el ISO VirtIO, instalar el paquete de controladores, añadir un disco VirtIO SCSI ficticio para forzar la enumeración, confirmar controladores y luego rehacer la migración. Pero la indisponibilidad ocurrió igualmente, porque se hizo una suposición equivocada al inicio: “un controlador aparecerá mágicamente al arrancar”.

La solución duradera no fue un script heroico. Fue un runbook de migración con un paso no negociable: preparar el controlador mientras la VM aún es arrancable.

Micro-historia 2: La optimización que salió mal

Un equipo diferente estaba orgulloso de su clúster Proxmox. Hardware sólido, ZFS y suficiente monitorización para despertar a los muertos. Notaron que los benchmarks de disco en una VM Windows eran “más bajos de lo esperado” y alguien decidió tunear para la gloria. Cambiaron el modo de caché a writeback, habilitaron discard en todas partes y activaron iothread para cada disco, en toda la flota, con prisa.

El rendimiento mejoró — a corto plazo. Luego un reinicio del host tras una actualización de kernel ocurrió. Un subconjunto de VMs volvió con errores en el sistema de archivos y corrupción a nivel de aplicación. El postmortem fue doloroso porque no había una única bala humeante; era una pila de suposiciones. El caché writeback puede ser seguro si entiendes de dónde viene el reconocimiento de escritura y qué ocurre en pérdida de energía o reinicios abruptos del host. En su entorno, esa historia de seguridad no estaba plenamente probada.

Tuvieron que revertir ajustes de caché, restaurar algunos datos desde backups y explicar a dirección por qué “tunar rendimiento” causó un evento de fiabilidad. La lección dura: los ajustes de rendimiento de almacenamiento no son gratis. Si no puedes explicar el modelo de durabilidad a un SRE escéptico, no lo despliegues.

El estado final fue mejor: mantuvieron iothread para discos específicos de alta I/O, usaron caché conservadora por defecto y solo activaron caché agresiva donde la app podía tolerar el riesgo y la infraestructura tenía las protecciones contra pérdida de energía adecuadas.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo gestionaba una nube privada pequeña con Proxmox y mezcla de Linux y Windows. Nada sofisticado. Su práctica “aburrida” era una lista de construcción estándar para VMs: siempre adjuntar ISO VirtIO, siempre instalar paquete VirtIO y QEMU guest agent, siempre verificar que el Administrador de dispositivos esté limpio, siempre snapshot antes de cambiar controladores de disco.

Luego llegó un proyecto de actualización: mover VMs Windows a VirtIO SCSI single por rendimiento y consistencia operativa. No fue glamuroso. Fue repetir mucho: añadir segundo disco VirtIO, arrancar, confirmar controlador, apagar, cambiar controlador, arrancar, validar, quitar disco de preparación.

A mitad del despliegue, una VM se negó a arrancar tras el cambio. Sin drama. Revirtieron usando el snapshot, arrancaron, descubrieron que el ISO VirtIO montado era una build antigua con problemas de firma bajo sus ajustes de Secure Boot, actualizaron el ISO, prepararon los controladores otra vez y completaron la migración.

Sin ticket de incidente, sin llamada de emergencia, sin atención ejecutiva. Lo aburrido ganó. Y en sistemas de producción, lo aburrido suele ser el mayor cumplido.

Una cita operativa (idea parafraseada)

Idea parafraseada (Werner Vogels): “Todo falla, todo el tiempo”, así que diseña sistemas y procedimientos asumiendo que la falla es normal.

Preguntas frecuentes (FAQ)

1) ¿Qué controlador VirtIO necesito: vioscsi o viostor?

VirtIO SCSI (controlador SCSI de Proxmox en VirtIO SCSI / VirtIO SCSI single) normalmente necesita vioscsi. VirtIO Block (disco virtio0) necesita viostor. Revisa qm config para confirmar lo que realmente configuraste.

2) ¿Por qué Linux ve el disco pero Windows no?

Los kernels de Linux generalmente incluyen los controladores VirtIO por defecto. Windows no incluye controladores de almacenamiento VirtIO en el entorno del instalador, por eso debes cargarlos desde el ISO VirtIO.

3) ¿Puedo instalar Windows en SATA primero y cambiar a VirtIO más tarde?

Sí, y es una solución táctica razonable. Solo no cambies en caliente el controlador del disco de arranque sin preparar el controlador primero. Añade un segundo disco VirtIO, instala controladores, confirma detección y luego cambia.

4) Cargué un controlador en Windows Setup, pero el disco aún no aparece. ¿Ahora qué?

Revisa el tipo de controlador (VirtIO SCSI vs VirtIO Block), la carpeta del controlador (versión correcta de Windows + amd64) y confirma que el ISO VirtIO está realmente montado. Si los logs del host muestran errores de I/O, para y arregla primero el almacenamiento host.

5) ¿El Secure Boot de Windows 11 bloquea los controladores VirtIO?

Puede suceder si usas un ISO VirtIO antiguo con problemas de firma respecto a tu política de Secure Boot. Usa un ISO VirtIO reciente y mantén las elecciones de firmware de la VM consistentes (UEFI sigue siendo UEFI).

6) ¿Cuál es la mejor elección de controlador de disco para Windows en Proxmox?

Para la mayoría de cargas de producción: VirtIO SCSI single con discos SCSI. Es un buen equilibrio entre rendimiento, características y predictibilidad operativa.

7) Cambié el controlador y ahora la VM no arranca. ¿Cuál es la recuperación más rápida?

Vuelve a cambiar el disco al controlador antiguo (SATA/IDE) para que Windows arranque. Luego instala los controladores VirtIO correctamente (preferiblemente añadiendo un disco VirtIO secundario). Después de confirmar los controladores, vuelve a intentar el cambio de controlador.

8) ¿Necesito QEMU Guest Agent para la visibilidad del disco?

No. No es un controlador de almacenamiento. Pero lo quieres para apagados limpios, mejor orquestación y menos momentos de “¿por qué no se detiene esta VM?”.

9) ¿Debo habilitar discard (TRIM) en el disco virtual?

Si tu backend se beneficia de la reclamación de espacio (thin provisioning, pools SSD) y entiendes el comportamiento de la pila de almacenamiento, sí. Si no estás seguro, empieza con conservador y mide. Un comportamiento de discard incorrecto no suele ocultar el disco, pero puede causar patrones de rendimiento inesperados.

10) ¿Por qué el ISO VirtIO tiene tantas carpetas?

Porque las versiones de Windows y los requisitos de firma difieren, y los controladores se empaquetan por familia de SO y arquitectura. El instalador necesita el conjunto exacto inf/sys/cat. “Casi suficiente” no es cómo funcionan los controladores de Windows.

Conclusión: siguientes pasos para evitar problemas

Si Windows no puede ver tu disco en Proxmox, trátalo como un desajuste contractual: Proxmox presentó un controlador; Windows necesita el controlador correcto para hablarlo. Arregla el desajuste, no deambules aleatoriamente por la configuración.

Instalaciones nuevas: usa VirtIO SCSI single desde el primer día y carga vioscsi en Setup desde el ISO VirtIO.
Instalaciones existentes: prepara los controladores primero (añade un disco VirtIO secundario), luego cambia el disco/controlador de arranque.
Cuando aún no funciona: valida la salud del almacenamiento host y el mapeo de la VM con comandos, no por intuición.

Haz esto de forma consistente y dejarás de tener “Windows no encuentra el disco” como ritual recurrente. Además, dormirás mejor, que es la verdadera métrica de rendimiento.