En corto

1
2

qm set 102 --cpu x86-64-v2-AES    # o x86-64-v3 si todos los hosts son Haswell / EPYC o más nuevos
qm stop 102 && qm start 102       # un reboot desde dentro de Windows NO aplica el cambio

Síntomas

Windows 10, 11 o Server con cpu: host: arranque lento, escritorio a tirones, congelamientos de segundos, todo lo que toque memoria va mal. La misma VM con x86-64-v2-AES responde normal. Una VM Linux con host en el mismo nodo no nota nada.

Por qué pasa

host le pasa a la VM todos los flags del CPU físico, incluidos dos que existen para las mitigaciones de vulnerabilidades de Intel:

FlagMitigaciónQué hace Windows al verlo
md_clearMDS (Microarchitectural Data Sampling)Ejecuta VERW en cada transición kernel ↔ usuario para vaciar buffers
flush_l1dL1TF (L1 Terminal Fault)Vacía la caché L1D en cada entrada a la VM / cambio de contexto

Dentro de una VM esas operaciones salen carísimas. Las mediciones del hilo original en el foro de Proxmox: en un Xeon E5-2667 v2 la latencia de lectura de RAM pasa de ~100 ns a ~2000 ns; en un i9-13900K, de 30 a 90 ns. Windows, que toca memoria del kernel todo el tiempo, se arrastra.

Los tipos genéricos (x86-64-v2-AES, x86-64-v3, IvyBridge-IBRS, …) no exponen esos dos flags, así que Windows ni ve la vulnerabilidad ni enciende la mitigación.

Qué tipo elegir

TipoRequiere en el hostNotas
x86-64-v2-AESIntel Westmere / AMD Opteron 4.ª gen o más nuevoDefault de la GUI desde PVE 8. Migra entre hosts distintos
x86-64-v3Intel Haswell / AMD EPYC o más nuevoAVX2. Migra entre hosts que lo cumplan
x86-64-v4Skylake-SP / Zen 4 o más nuevoAVX-512
hostTodos igualesMáximo de flags, pero no migra entre CPUs distintos y trae este problema en Windows

Elige el más alto que soporten todos los nodos del clúster:

1

grep -o -w -E 'avx2|avx512f' /proc/cpuinfo | sort -u   # avx2 → v3 ok; avx512f → v4 ok

Es la recomendación del staff de Proxmox en ese mismo hilo: usar el x86-64-v* que corresponda al hardware en vez de apagar flags de seguridad a ciegas.

Si insistes en host

Hay casos en los que host hace falta: virtualización anidada (Hyper-V, WSL2 dentro de la VM, un lab de ESXi), porque los tipos x86-64-v* no exponen vmx/svm. Puedes quitar md_clear con la opción flags:

1

qm set 102 --cpu host,flags=-md-clear

Pero flush_l1d no está en la lista de flags que Proxmox deja tocar, así que te quedas con la mitad del problema. Y ocultarle mitigaciones al guest es una decisión de seguridad: razonable en un nodo de un solo dueño, no en uno con inquilinos que no controlas.

Comprobar desde dentro de Windows

El módulo oficial de Microsoft muestra qué mitigaciones tiene activas el guest:

1
2

Install-Module SpeculationControl -Scope CurrentUser
Get-SpeculationControlSettings

Con host, MDSWindowsSupportEnabled y L1TFWindowsSupportEnabled salen True; con x86-64-v2-AES, False. Es la forma rápida de confirmar que el cambio aplicó.

Trampas

  • El cambio pide stop/start. El tipo de CPU se fija al lanzar el proceso QEMU; un reinicio desde dentro del guest no lo toca.
  • Es un tema de Intel. md_clear y flush_l1d no existen en AMD; con host en EPYC/Ryzen no verás esta caída (aunque host sigue impidiendo migrar entre CPUs distintos).
  • Aplica a VMs nuevas también. Las plantillas creadas con host heredan el problema; cámbialo en la plantilla.
  • Con ambos tipos Windows sigue seguro contra lo que importa dentro de una VM: las mitigaciones que cuentan (Spectre v2, etc.) siguen activas; lo que desaparece es la doble mitigación de vulnerabilidades que ya mitiga el host.

Referencias: hilo del foro de Proxmox y la sección CPU de la guía de administración.