Windows 11 en Proxmox falla para varios usuarios avanzados sin causa clara

Pocas situaciones resultan tan frustrantes como encontrarse con un problema cuando has hecho todo según el manual.

Compras una CPU de gama alta y la combinas con memoria DDR5 rápida, almacenamiento NVMe de última generación, una GPU moderna y una instalación limpia de Proxmox. Sobre el papel, el equipo debería volar. Las máquinas virtuales Linux funcionan a gran velocidad, las pruebas de rendimiento en el host son impecables, las temperaturas están bajo control y las frecuencias boost responden cuando se necesitan.

Luego inicias una máquina virtual nueva con Windows 11, abres el Administrador de tareas y todo parece ir mal.

Las aplicaciones tardan en responder y la interfaz gráfica sufre retrasos constantes. Las puntuaciones en Cinebench parecen las de un portátil de hace una década. Windows asegura que tu potente procesador multihilo opera a una frecuencia sospechosamente fija de 2.0GHz, y ningún ajuste parece alterar esa cifra.

Para un número creciente de usuarios avanzados, esto se ha convertido en un comportamiento que un simple fallo de configuración no explica, y por ahora no hay consenso sobre qué está fallando realmente.

La configuración que debería ser imposible de arruinar

Los equipos afectados comparten un patrón similar: procesadores Intel modernos con arquitectura híbrida, Proxmox como hipervisor, Windows 11 como sistema operativo invitado, a menudo con passthrough de GPU, y concebidos como estaciones de trabajo de alto nivel antes que como experimentos de homelab.

En el host, todo funciona exactamente como se espera. El procesador alcanza frecuencias boost de 5GHz o más, el rendimiento del disco es extraordinario, el passthrough de la GPU opera sin incidentes, la red responde y las máquinas virtuales Linux son muy ágiles.

Dentro de Windows 11, sin embargo, el rendimiento colapsa. Las pruebas multihilo obtienen apenas unos 3,000 puntos cuando deberían situarse cerca de los 30,000. Aplicaciones pesadas tardan minutos en abrirse, el Explorador de archivos se congela y el Administrador de tareas muestra un uso de CPU prácticamente nulo mientras el sistema se arrastra.

Windows siempre informa de que hay un hipervisor presente. Eso no sorprende. Lo que desconcierta es la persistencia del bajo rendimiento, sin importar qué parámetros modifiques.

La falsa pista de los 2.0GHz

Uno de los primeros detalles que llama la atención es la velocidad de reloj. Windows indica que la CPU tiene un tope de aproximadamente 1997MHz, un dato llamativo pero engañoso. Bajo KVM, Windows no tiene acceso directo a la escala de frecuencias en tiempo real, por lo que a menudo muestra la frecuencia base del TSC en lugar del comportamiento boost real.

En condiciones normales esto carece de importancia, porque aunque el valor mostrado sea inexacto, el rendimiento está presente. En este caso no lo está. Las bajas puntuaciones en Cinebench y la lentitud real confirman que el problema va más allá de un número visual. Algo impide de forma activa que Windows utilice la CPU como debería.

E-cores, P-cores y el laberinto de la afinidad de núcleos

La primera hipótesis importante apunta al diseño de núcleos híbridos de Intel. Los procesadores i9 modernos combinan núcleos de rendimiento y núcleos de eficiencia, y Linux no siempre los organiza en un orden intuitivo. Si asignas la máquina virtual a CPU lógicas equivocadas, puedes terminar ejecutando una carga pesada de Windows casi por completo sobre núcleos de eficiencia.

Esa explicación resulta creíble y ha ocurrido antes. Herramientas como lscpu pueden inducir a error por omisión, mientras que hwloc refleja una topología muy diferente. Varios usuarios asumieron que este era el origen del fallo.

Sin embargo, muchos de los afectados revisaron minuciosamente su entorno. Comprobaron el mapa de núcleos con lstopo, asignaron únicamente núcleos de rendimiento confirmados y configuraron sockets, núcleos e hilos de manera idéntica. Windows reconoció la topología esperada y el rendimiento no mejoró en absoluto. Si solo fuera un problema de asignación de núcleos, ajustar la afinidad lo habría solucionado, pero para muchos no cambió nada.

Optimizaciones de Hyper-V: ¿mejora o trampa?

Otro grupo de usuarios señala las optimizaciones de Hyper-V. Windows espera ciertas indicaciones de paravirtualización cuando se ejecuta bajo un hipervisor. Estas existen como atajos de rendimiento y no para detectar el entorno: reducen las salidas de la máquina virtual hacia el host, optimizan la gestión de interrupciones y evitan operaciones lentas e innecesarias.

Desesperados por una solución, bastantes usuarios probaron desactivando todas las opciones de Hyper-V, ocultando KVM y simplificando la máquina virtual para que pareciera un equipo bare metal, buscando esquivar restricciones de Windows o de los controladores de GPU. El resultado pudo haber sido mutilar el rendimiento aún más.

Varios administradores experimentados de Proxmox sostienen que retirar esas optimizaciones, en especial junto a kvm=off, fuerza a Windows a un modo de compatibilidad mínimo. Sigues teniendo una máquina virtual, pero sin las mejoras que la hacen rápida.

Eso encaja con los síntomas observados. No obstante, algunos usuarios restauraron todos los parámetros recomendados de Hyper-V, eliminaron kvm=off y tampoco notaron mejoras. En ese punto, la sospecha deja de centrarse en la configuración.

La sospecha sobre Windows 11 24H2

Aquí es donde el escenario se vuelve más complejo. Diversos informes coinciden en el mismo patrón: versiones anteriores de Windows funcionan bien, las máquinas virtuales Linux funcionan bien, Windows 10 funciona bien y Windows 11 23H2 funciona bien. Windows 11 24H2 no.

Las instalaciones limpias de 24H2 presentan problemas desde el primer inicio. Volver a imágenes ISO más antiguas devuelve el rendimiento normal en el mismo host de Proxmox y con la misma configuración de VM.

Esto sugiere con fuerza una regresión, ya sea en Windows o en la forma en que QEMU presenta ciertas características de CPU a las compilaciones más recientes. Hay precedentes de situaciones similares. Microsoft ha endurecido progresivamente la seguridad basada en virtualización, sumando capas como VBS, HVCI y modificaciones profundas en el planificador. La mayoría de las veces los hipervisores se adaptan con transparencia. En ocasiones no ocurre así, y este parece ser uno de esos casos.

"Es Proxmox". "No, es QEMU". "No, es Windows".

Pregunta a diez administradores qué está fallando y obtendrás tres respuestas tajantes. Algunos afirman que Proxmox aún no se ha adaptado a los últimos cambios de Windows. Otros aseguran que Proxmox es solo una interfaz y que el problema reside directamente en QEMU. Un tercer grupo culpa a Microsoft por introducir supuestos técnicos que no se sostienen fuera de Hyper-V.

Lo que complica todo es que cada postura suena coherente, y ninguna explica por qué configuraciones idénticas presentan comportamientos tan dispares según la versión de Windows.

La falta de una causa probada convierte el problema en algo desesperante. No hay pánicos en el kernel, no hay errores evidentes en los registros ni existe un único parámetro que lo resuelva para todos; solo un Windows lento, un uso ínfimo de CPU y muchas horas perdidas.

El debate interminable sobre el tipo de CPU

Un ajuste temporal se repite continuamente en los foros: evitar el uso de cpu: host. Algunos usuarios afirman que cambiar a un modelo genérico de CPU x86-64 v2 o v3, reinstalando Windows desde cero a continuación, soluciona mágicamente el problema. La hipótesis sugiere que exponer demasiadas funciones avanzadas de la CPU empuja a Windows a habilitar rutinas que rinden mal bajo KVM.

El inconveniente es que muchos usuarios intentaron exactamente eso sin obtener ningún cambio. Puede servir en combinaciones muy concretas, pero no funciona en otras, pareciéndose más a una lotería que a una solución técnica real.

Por qué este problema duele más que un fallo común

Estos equipos son estaciones de trabajo destinadas a CAD, renderizado 3D, desarrollo y tareas creativas, muy lejos de un laboratorio secundario. La razón de usar Proxmox aquí es la consolidación: un único servidor potente que lo resuelva todo. Cuando Windows dentro de esa máquina rinde como si funcionara sobre una CPU de hace 10 años, toda la propuesta pierde su sentido. Y dado que las máquinas virtuales Linux rinden bien, resulta difícil justificar formatear el host solo para contentar a Windows.

La situación en este momento

A día de hoy no existe una solución aceptada de forma unánime. La medida más fiable parece ser evitar Windows 11 24H2, conservar versiones anteriores o mantenerse en Windows 10. No es lo ideal ni representa una estrategia a largo plazo, y tampoco ayuda a quienes han reinstalado varias veces buscando respuestas.

Lo que falta es coordinación técnica: un informe de error contrastado y un caso de prueba reproducible que Proxmox, QEMU o Microsoft no puedan desestimar. Mientras eso no ocurra, el problema permanece en el peor escenario posible: real, molesto y lo bastante confuso como para que cada parte crea que la culpa es de otra.

Qué lección sacar de todo esto

Si hoy ejecutas Windows 11 sobre Proxmox y todo funciona con fluidez, perfecto. Disfrútalo.

Si estás planificando un nuevo equipo de gama alta, sin embargo, este es uno de esos momentos donde adoptar tecnología puntera pasa factura. Las CPU híbridas, los lanzamientos frecuentes de Windows y las pilas complejas de virtualización no siempre encajan bien, incluso cuando cada componente por separado funciona a la perfección.

Windows 11 sobre Proxmox no está roto para todos los usuarios en este momento, pero para ciertos perfiles avanzados sin duda lo está. Hasta que la comunidad o los fabricantes identifiquen la causa exacta, la solución más prudente puede ser la que menos apetece: posponer la actualización.