
virtio-win 0.1.302 es estable: ¿deberías actualizar?
virtio-win 0.1.302 aparece etiquetado como estable, pero eso no implica que todas las máquinas virtuales Windows en Proxmox deban recibirlo hoy. La publicación llega tras una racha accidentada para los controladores de almacenamiento de Windows, incluida una regresión grave de vioscsi en Windows Server 2025 dentro de 0.1.285, y el debate en torno a 0.1.302 demuestra cuánto contexto exige la palabra "estable".
El paquete apareció en la ruta de descargas estables de Fedora virtio-win el 27 de agosto de 2026. Los administradores comenzaron a probarlo de inmediato en Windows Server 2025, Windows 11, cargas de trabajo de SQL Server, máquinas virtuales de Proxmox respaldadas por ZFS y flujos de copia de seguridad. Algunos obtuvieron resultados limpios. Otros comprobaron que comportamientos no relacionados de almacenamiento, en especial TRIM, todavía requerían ajustes manuales. Una versión de controladores puede ser oficialmente estable mucho antes de demostrar que es estable para tu carga de trabajo concreta, y 0.1.302 es un buen ejemplo.
¿Qué cambió con virtio-win 0.1.302?
A finales de agosto de 2026, 0.1.302 pasó a ser el paquete estable actual de Fedora, sustituyendo a 0.1.285 en la ubicación de descarga estable.
La entrada del registro de cambios de Fedora que citaron los primeros evaluadores tenía fecha del 27 de agosto e identificaba el paquete como 0.1.302-1. El paquete incluía la ISO, paquetes RPM, herramientas para el invitado de Windows y los instaladores MSI para x64 y x86.
Esto interesa a los usuarios de Proxmox porque virtio-win proporciona los controladores de invitado de Windows para el hardware virtual habitual: VirtIO SCSI, VirtIO Block, adaptadores de red VirtIO, ballooning de memoria, dispositivos serie y componentes asociados. El proyecto original describe virtio-win como el conjunto de controladores paravirtualizados de Windows para QEMU y KVM. En Proxmox, estos controladores residen directamente en la ruta de E/S entre Windows y el hardware virtual que expone QEMU.
Por tanto, un controlador de almacenamiento defectuoso es mucho peor que un simple fallo estético en las herramientas del invitado. Un error en el almacenamiento puede perjudicar a bases de datos, archivos de paginación, copias de seguridad, lecturas de disco, TRIM o la estabilidad de la VM bajo carga.
Si creas o mantienes invitados Windows en Proxmox, los recursos de Proxmox de Mr.PlanB ayudan a situar la configuración del invitado y la arquitectura del host bajo una misma perspectiva.
¿Por qué los administradores estaban inquietos tras 0.1.285?
Por lo ocurrido con 0.1.285. Una incidencia documentada en vioscsi afectó a cargas de trabajo intensivas en E/S con Windows Server 2025, en particular sobre SQL Server. El informe de GitHub para la incidencia 1453 describía un comportamiento de reintentos de lectura: SQL Server registraba errores de suma de comprobación o de ID de página en la primera lectura y luego la completaba con éxito en el reintento.
El usuario que informó del error rastreó la regresión hasta controladores más recientes que incluían un cambio concreto y afirmó que 0.1.271 no reproducía ese fallo con la carga analizada. El caso fue tan grave que la documentación de controladores VirtIO para Windows de Proxmox señaló 0.1.285 como un problema conocido para VirtIO SCSI y VirtIO Block en máquinas virtuales de Windows Server 2025 con uso intensivo de E/S.
Ese historial condicionó la reacción hacia 0.1.302. Un administrador en el debate lo resumió con acierto: tras la experiencia con 0.1.285, primero prueba y espera. Otro comentó haber sufrido el fallo en persona con cargas de SQL Server. Un usuario distinto aseguró que una base de datos de producción se corrompió de forma inadvertida a lo largo del tiempo antes de que nadie comprendiera la incidencia. Este último caso es anecdótico y no puede extrapolarse a todos los entornos, pero explica por qué los operadores experimentados no consideraron una nueva etiqueta de estable como prueba suficiente para una actualización masiva.
0.1.285 no resultó inutilizable para todo el mundo. El problema radica en que una versión puede superar las pruebas estándar y fallar igualmente ante una carga de trabajo concreta, una versión del sistema operativo, un patrón de concurrencia o una ruta de almacenamiento específica.
¿Solucionó 0.1.302 el problema de lectura en Windows Server 2025?
Las primeras comprobaciones indican que el problema concreto de reintentos de lectura en vioscsi se solucionó, aunque persisten otras incidencias de almacenamiento. El reporte original de Windows Server 2025, la incidencia 1453 de GitHub, se acabó cerrando. Quienes siguieron la pista a 0.1.302 señalaron el trabajo de desarrollo asociado e indicaron que el fallo de E/S quedó corregido en la compilación más reciente.
Las primeras pruebas prácticas fueron alentadoras. Un usuario actualizó varias máquinas virtuales con Windows 11 y Windows Server 2025 sin observar incidencias inmediatas. Otro ejecutó una base de datos de prueba de un ERP con SQL durante varias horas de comprobaciones y afirmó que los errores de lectura previos no reaparecieron. Son datos útiles, pero siguen siendo pruebas operativas iniciales.
Conviene separar también los fallos. El mismo hilo derivó rápidamente de la regresión de reintentos de lectura en Windows Server 2025 a los problemas con TRIM en VMs sobre ZFS, y un participante puntualizó que eran dos cuestiones distintas. Cuando surgen varios síntomas de almacenamiento en torno a la misma familia de controladores, es fácil perder la perspectiva.
Corregir el reintento de lectura en SQL Server no repara de forma automática el TRIM de Windows. Una prueba limpia en Windows Server 2025 no demuestra que la ruta de viostor en Windows 10 funcione bien. Un único paquete puede contener varios controladores de almacenamiento, cada uno con su propio código y sus propios modos de fallo.
¿Por qué TRIM seguía provocando debate tras 0.1.302?
Algunos evaluadores detectaron que TRIM seguía fallando en Windows tras actualizar a 0.1.302, sobre todo con discos VirtIO SCSI sobre zvols de ZFS.
La incidencia 1574 de GitHub documenta un invitado con Windows 11 donde TRIM dejó de funcionar con virtio-win 0.1.285 tras una actualización de Windows en mayo de 2026. El fallo generaba el evento de desfragmentación de Windows con ID 264 e impedía que las peticiones de descarte avanzaran por la pila de almacenamiento del invitado como debían.
En el debate sobre 0.1.302, un administrador actualizó los controladores, confirmó la nueva versión en el Administrador de dispositivos, reinició y aun así comprobó que:
defrag /O c:
fallaba a menos que se añadiera un parámetro discard_granularity en la configuración de la VM de Proxmox.
Se probaron valores como 16K, 32K y 64K en función del tamaño de bloque del zvol de ZFS y de la unidad de asignación de NTFS. El debate se volvió minucioso porque el valor adecuado depende de cómo encajan las peticiones de descarte entre el sistema de archivos del invitado, el disco virtual y el volumen ZFS subyacente. Ni "0.1.302 arregla TRIM" ni "0.1.302 rompe TRIM" constituyen un resumen justo.
A fecha de septiembre de 2026, la incidencia correspondiente a TRIM continuaba abierta en el proyecto upstream. La conclusión prudente es más acotada: 0.1.302 puede resolver una regresión de almacenamiento mientras un problema independiente con el descarte persiste en determinadas configuraciones.
¿Qué ocurre con la corrupción del archivo de paginación en viostor?
Otra incidencia abierta dificulta aún más una recomendación general. La incidencia 1614 de GitHub reporta corrupción en el archivo de paginación con el controlador viostor en 0.1.285.
Se trata de un problema diferente al fallo de vioscsi en Windows Server 2025. Describe Windows 10 sobre un disco VirtIO Block, donde los datos del archivo de paginación escritos a través de viostor podían leerse incorrectamente y desencadenar comprobaciones de error del tipo MEMORY_MANAGEMENT.
El autor del informe comparó 0.1.285 con 0.1.271 manteniendo el mismo hardware de almacenamiento y prácticamente todo el entorno de la VM. En esa prueba, 0.1.285 falló con el script de reproducción y 0.1.271 completó rondas repetidas sin problemas. A fecha de 17 de septiembre de 2026, la incidencia seguía abierta en el proyecto upstream.
Nada de eso demuestra que 0.1.302 presente el mismo fallo. Sí demuestra por qué "el paquete estable más reciente" es un motivo demasiado débil para actualizar controladores de almacenamiento de Windows en una VM crítica. Antes de dar el paso, investiga qué controlador utiliza la máquina virtual, qué carga de trabajo lo estresa y si la incidencia upstream en esa ruta está realmente resuelta en la versión que piensas instalar. Esas respuestas te aportarán más información que la propia etiqueta de estable.
¿Significa estable que está listo para producción?
Estable es la etiqueta de un canal de distribución, mientras que apto para producción es una valoración que realizas sobre una carga de trabajo concreta tras una validación suficiente. Gran parte del debate se redujo a esa diferencia.
Algunos usuarios interpretaron la designación de estable de Fedora como una señal fiable de que 0.1.302 había superado el proceso de publicación y estaba listo para uso general. Otros habían tenido malas experiencias con 0.1.285 y prefirieron mantenerse en 0.1.271, que ya les había resultado fiable.
Un administrador describió un criterio simple: ejecutar el nuevo controlador en una VM casi productiva durante aproximadamente un mes, vigilar los registros de Windows y solo entonces evaluar la actualización del resto de los servidores. Es un enfoque conservador, y para controladores de infraestructura tiene todo el sentido. Que falle la actualización de un navegador resulta molesto. Que un controlador de almacenamiento devuelva datos incorrectos bajo carga representa un riesgo mucho más grave.
Eso no significa quedarse anclado para siempre en controladores antiguos. Las versiones viejas tienen sus propios fallos, límites de compatibilidad y parches ausentes. Actualiza cuando tengas un motivo real; que aparezca un número de versión superior no lo es.
Si 0.1.302 resuelve un problema de Windows Server 2025 que ya sufres, evaluarlo resulta claramente conveniente. Si tus invitados funcionan de forma estable con 0.1.271 y ninguna de las mejoras te hace falta, la urgencia es mucho menor.
¿Cómo conviene probar 0.1.302 antes de un despliegue amplio?
Empieza con una máquina virtual que refleje la carga de trabajo que te interesa pero que sea fácil de restaurar. Una instantánea por sí sola no constituye un plan de seguridad completo. Ten a mano una copia de seguridad real, anota las versiones de controladores actuales y ten claro cómo revertirás el controlador de almacenamiento si el invitado se vuelve inestable.
Prueba después las operaciones reales de tu VM de producción. Con una carga SQL en Windows Server 2025, genera operaciones continuadas de E/S en la base de datos y revisa tanto los registros de SQL Server como el Visor de eventos de Windows. En una VM Windows sobre ZFS, prueba TRIM o Desfragmentar y optimizar unidades, y confirma que el descarte llega al almacenamiento subyacente. Para una VM con VirtIO Block, revisa el historial de incidencias de viostor y no des por hecho que los resultados de vioscsi se aplican igual.
Evalúa los backups de forma independiente. En el mismo debate, alguien informó de que Synology Active Backup dejó de funcionar tras actualizar a 0.1.302 y se recuperó al volver a 0.1.271. Otro participante indicó que diferentes comportamientos relacionados con las copias de seguridad mejoraron con versiones más nuevas del agente de invitado. Ninguno de los dos comentarios es un veredicto definitivo de compatibilidad, pero ambos son buenas razones para verificar copias y restauraciones tras modificar controladores de bajo nivel.
Una revisión con Proxmox Health Check puede ayudar en el host y en el clúster, pero la validación del invitado Windows tiene que llevarse a cabo dentro de la propia VM.
La versión más segura es la que realmente has probado
0.1.302 es una versión relevante. Llega tras los problemas conocidos en la generación 0.1.285, y las primeras pruebas sugieren que mitiga al menos algunos de los casos más preocupantes en Windows Server 2025. Con todo, la etiqueta de estable no da luz verde a todo.
Una pregunta de actualización más acertada que "¿Es estable 0.1.302?" consiste en averiguar si 0.1.302 resulta más conveniente para esta VM, esta versión de Windows, este controlador de almacenamiento virtual, esta carga de trabajo y esta ruta de backup.
Si las pruebas responden que sí, actualiza. Si tu controlador actual funciona y 0.1.302 no aporta nada que necesites en este momento, no hay ningún premio por ser el primero.
Preguntas frecuentes
¿Es virtio-win 0.1.302 estable para máquinas virtuales Windows en Proxmox?
El paquete 0.1.302 se publicó como versión estable a finales de agosto de 2026, pero la etiqueta de estable no elimina los riesgos para todas las cargas de trabajo de Proxmox. Informes sobre controladores de almacenamiento, TRIM y agentes de backup aconsejan probarlo por fases.
¿Solucionó virtio-win 0.1.302 el problema de E/S en Windows Server 2025?
El fallo de reintento de lectura en vioscsi con 0.1.285 y Windows Server 2025 se atribuyó a una regresión en el controlador y luego se cerró. Las primeras pruebas de 0.1.302 fueron positivas, aunque otros problemas de almacenamiento son independientes.
¿Debería actualizar de virtio-win 0.1.271 a 0.1.302?
Actualiza si 0.1.302 corrige un problema real que sufras o añade algo necesario, validándolo primero en una VM no crítica. Si 0.1.271 es estable para tu carga de trabajo, hay pocos motivos para cambiar todos los controladores de producción de inmediato.