Windows Update puede romper una VM de Proxmox en AMD EPYC

Un mensaje de agosto de 2026 en el foro de Proxmox informa de que una VM con Windows Server 2019 volvió a dejar de arrancar tras Windows Update en un host AMD EPYC que usa el argumento personalizado de QEMU -cpu host,-hypervisor. Es un problema de compatibilidad concreto comunicado por la comunidad, y no demuestra que la actualización de agosto rompa todas las VMs Windows en Proxmox.

Microsoft publicó la actualización KB5120238 para Windows Server 2019 el 11 de agosto de 2026, que lleva el sistema operativo a la compilación 17763.9121. La nota de la versión de Microsoft no recoge por ahora ningún problema conocido que coincida con el informe de Proxmox, así que reproducirlo con cuidado importa más que las afirmaciones generales sobre Microsoft o sobre Proxmox.

El historial del foro es útil porque el mismo administrador llevaba desde enero de 2026 siguiendo fallos de arranque parecidos en un sistema AMD EPYC 7302P. Los apaños anteriores con el modelo de CPU devolvieron el arranque tras actualizaciones previas. El 16 de agosto, quien informó dijo que esos apaños ya no funcionaban para un invitado Windows Server 2019.

¿Es un bug confirmado de Microsoft o de Proxmox?

Con las pruebas disponibles, nadie ha establecido públicamente un defecto confirmado de ningún fabricante. La prueba más sólida es un caso largo del foro de Proxmox con información detallada del host y del invitado, más otro participante que probó otra generación de AMD EPYC y obtuvo resultados distintos.

Microsoft dice que KB5120238 no tiene problemas conocidos por ahora, y Proxmox no ha publicado ningún aviso de que la actualización de agosto de Windows Server rompa de forma general los invitados en AMD EPYC. Un único caso reproducible puede ser real e importante, pero hasta que se aísle la causa de fondo hay que describirlo como un informe de compatibilidad.

Es la disciplina normal al diagnosticar infraestructura: empieza por la afirmación más pequeña que respaldan las pruebas. Una configuración dejó de arrancar tras una actualización. Esa configuración incluye un argumento de CPU que no es el predeterminado, se vieron fallos parecidos tras actualizaciones anteriores de Windows y distintos modelos de CPU cambiaron el resultado en pruebas anteriores.

Eso justifica un plan de pruebas. No justifica decirle a todos los administradores de Proxmox con AMD EPYC que desinstalen actualizaciones de seguridad.

¿Qué configuración exacta de Proxmox dejó de arrancar?

El informe original de enero venía de Proxmox VE 8.4 en un HPE DL325 Gen10 con un AMD EPYC 7302P, un procesador Zen 2 Rome. El software indicado incluía el kernel 6.8.12-18-pve, pve-manager 8.4.16, pve-qemu-kvm 9.2.0-7 y qemu-server 8.4.5.

El administrador contó que invitados Windows 10 ESU y Windows Server 2019, 2022 y 2025 funcionaban con el argumento personalizado -cpu host,-hypervisor antes de una actualización de Windows, y que después se colgaban antes de la animación de arranque normal. El mismo comportamiento no se reprodujo en un sistema Intel E-2346, lo que metió de inmediato en la investigación la forma en que se presenta la CPU.

Durante las pruebas de febrero, quien informó descubrió que presentar un modelo EPYC más genérico podía devolver el arranque en algunos casos. Otro participante con PVE 9.1.5 y un AMD EPYC 9135 más reciente contó que Windows Server 2025 arrancaba con otra configuración de CPU de Proxmox.

En agosto, quien informó originalmente dijo que una VM con Windows Server 2019 se había vuelto a romper con -cpu host,-hypervisor, y que los apaños antiguos basados en el modelo ya no la arreglaban. Ahí está el hilo público a fecha de 17 de agosto.

¿Por qué importa el flag de CPU -hypervisor?

El argumento personalizado cambia las funciones de CPU que QEMU presenta al invitado Windows. Proxmox permite ajustar los modelos y los flags de CPU porque las funciones de virtualización, la compatibilidad para migrar, la virtualización anidada, la detección del invitado y el rendimiento pueden depender de la interfaz de CPU virtual.

En la sintaxis de QEMU, un signo menos delante desactiva un flag de CPU. En esta configuración, -hypervisor oculta al invitado el flag de CPU relacionado con el hipervisor. Históricamente, los administradores han usado ajustes parecidos para comportamientos especiales del invitado, experimentos de virtualización anidada, compatibilidad de software o para intentar ocultar la virtualización a las aplicaciones.

Presentar la CPU de forma personalizada añade otra capa de compatibilidad. Windows toma decisiones según la familia del procesador, los bits de funciones, las capacidades de virtualización, el firmware y las funciones de seguridad activadas que ve, así que una actualización mensual puede cambiar código que depende de esas señales aunque el hipervisor no haya cambiado.

Los flags personalizados no están mal en sí mismos, pero trátalos como parte del contrato de compatibilidad de la aplicación. Si una VM depende de -hypervisor, anota por qué. Si ya nadie sabe por qué existe el flag, arrastras una deuda de configuración que vale la pena eliminar en una prueba controlada.

¿Por qué ayudaron los apaños anteriores con el modelo de CPU?

Antes en el hilo del foro, cambiar el modelo de CPU virtual alteraba el resultado del arranque. EPYC-Rome-v4 con el flag de hipervisor oculto no arrancó en una prueba, mientras que una presentación EPYC más genérica sí. Otro experimento forzó un modelo EPYC más antiguo y también devolvió el arranque durante un tiempo.

Ese patrón sugiere que el invitado reacciona a la combinación de la identidad del procesador expuesta y los flags de virtualización, más que a una simple falta de rendimiento de CPU. No nos dice qué ruta de código de Windows cambió ni si el comportamiento es intencionado.

Aquí los consejos genéricos de ajuste se vuelven peligrosos. Copiar una cadena de CPU de un foro puede hacer que un invitado arranque mientras le quita capacidades de CPU sin avisar, cambia el comportamiento de la migración, afecta a la virtualización anidada o crea otro problema meses después.

La guía de rendimiento de Windows Server 2025 de Mr.PlanB sigue el enfoque más seguro: comparar configuraciones controladas, anotar la referencia y cambiar una variable cada vez. La compatibilidad del arranque merece el mismo cuidado.

¿Conviene desinstalar KB5120238 si una VM de Proxmox no arranca?

No como primer paso. KB5120238 es una actualización de seguridad, y Microsoft recomienda instalar las actualizaciones de seguridad actuales. Quitarla sin entender el fallo puede cambiar un problema de arranque por una exposición de seguridad y quizá solo aplace el mismo problema hasta la siguiente actualización acumulativa.

Primero confirma la correlación. Clona o restaura la VM en un entorno de pruebas aislado si puedes. Anota la configuración exacta de la VM, sobre todo el modelo de CPU, los args personalizados, el tipo de máquina, el tipo de BIOS, la configuración de TPM, los requisitos de virtualización anidada y la compilación de Windows. Después prueba el mismo invitado con la configuración de CPU compatible más básica que cubra las necesidades reales de la carga de trabajo.

Si la VM solo arranca después de quitar un flag personalizado, tienes una pista mucho mejor que la que te daría revertir Windows a ciegas. Si la VM sigue fallando con una configuración estándar y compatible, se refuerzan los motivos para escalar el caso a Microsoft y a Proxmox con logs reproducibles.

El caso de estudio de la actualización a Proxmox 9.1 es pertinente por el mismo motivo: los fallos de infraestructura son más fáciles de diagnosticar cuando el equipo conserva un estado que se sabe bueno y puede comparar un cambio con otro.

¿Cómo deberían probar los equipos de producción las actualizaciones de Windows en Proxmox?

Antes de un despliegue amplio, usa una VM canario que coincida con el modelo de CPU y los flags poco habituales de producción. Una VM Windows de prueba genérica no basta si producción depende de passthrough de GPU, Hyper-V anidado, VBS, ajustes CPUID personalizados, firmware antiguo o una generación concreta de AMD EPYC.

Tras aplicar el parche, el canario debería arrancar, reiniciar, apagarse y ejecutar la carga de trabajo real del servicio. Si el entorno usa Windows Failover Clustering, virtualización anidada, SQL Server, Remote Desktop Services o funciones de seguridad como Credential Guard, pon a prueba también esas funciones.

Mantén la vía de marcha atrás independiente de la VM que se actualiza. Un snapshot puede servir para una prueba corta, pero una copia de seguridad como es debido es más segura para revertir en producción, porque los snapshots comparten el mismo almacenamiento subyacente y el mismo dominio de fallo. Si la VM no arranca, necesitas un método de recuperación que no dependa de que Windows arranque bien.

Sobre todo, exporta la configuración de la VM junto con el proceso de backup. Una imagen de disco sin los flags de CPU, los ajustes de firmware, el hardware virtual y el orden de arranque puede no reproducir el estado funcional que intentas recuperar.

¿Qué haría hoy con este caso de AMD EPYC?

No bloquearía las actualizaciones de seguridad de Windows de agosto en todo un parque Proxmox por un solo informe del foro. Identificaría los invitados Windows que usan argumentos de CPU personalizados como -hypervisor, sobre todo en hosts AMD EPYC, y pasaría esos sistemas a un anillo de pruebas de preproducción más estricto.

Para una VM afectada, conservaría la configuración que funciona y una copia de seguridad recuperable, y luego probaría una copia con los ajustes de CPU estándar de Proxmox antes de quitar la actualización de seguridad. Si la configuración estándar arranca, decidiría si el flag personalizado sigue siendo necesario de verdad. Si no arranca, recogería logs y abriría casos con los fabricantes con una configuración mínima reproducible.

Este caso muestra que el comportamiento personalizado de la CPU virtual pasa a formar parte de tu cadena de dependencias, y que las actualizaciones mensuales del sistema operativo pueden dejar al descubierto esa dependencia años después de que alguien añadiera una línea a la configuración de una VM. No demuestra que Windows Update sea inseguro ni que AMD EPYC sea una mala plataforma para Proxmox. Los equipos que llevan bien estas cosas saben qué VMs son especiales antes de que un Patch Tuesday se lo demuestre.