Dos valores por defecto de Proxmox VE 9 que quizá no tengas: enlightenments de Hyper-V y microcódigo de CPU

Dos ajustes que hiciste una vez y olvidaste

Proxmox VE 9 hace dos cosas útiles por ti sin que se lo pidas. Le da a un invitado Fisher-Price OS (Windows) las funciones paravirtuales que necesita para ir bien sobre KVM, y carga microcódigo de CPU actual en el arranque.

Las dos son automáticas. Las dos dependen también de una decisión que tomaste una vez, quizá hace años, y que no has vuelto a mirar.

La primera depende del OS Type que elegiste al crear la VM. Elige una de las entradas Microsoft Windows y Proxmox añade los enlightenments de Hyper-V en cada arranque. Déjalo en Other, cosa fácil cuando importas un disco o clonas algo viejo, y el invitado no recibe ninguno. Arranca, funciona, va más lento, y nada te lo dice.

La segunda depende de cómo llegó el host a la versión 9. El instalador de la 9.0 activa el componente de firmware de Debian e instala el paquete de microcódigo de tu CPU. Un host actualizado desde la 8.x conserva los repositorios que tenía, y en la mayoría eso significa ningún paquete de microcódigo. En un host AMD Zen 5 con el kernel 6.17.9 o posterior, no es un hueco teórico: los invitados con los tipos de CPU EPYC dejan de arrancar.

El resto del post los trata por turnos: qué es cada uno, la regla exacta que aplica Proxmox, cómo activarlo donde falta y cómo demostrar que ha cogido. Las reglas salen del código de qemu-server y pve-manager en un host 9.2 en marcha, no de memoria, porque dos de ellas no son lo que casi nadie adivinaría.

Qué es de verdad un enlightenment

Un sistema operativo invitado escrito para hardware real gasta mucho esfuerzo en cosas que dentro de una VM son un derroche. Programa temporizadores a través de chips emulados, da vueltas esperando cerrojos que tiene una vCPU que ni siquiera está planificada, y dispara watchdogs cuando el host le roba unos milisegundos.

La paravirtualización lo arregla dejando que el invitado sepa que es un invitado y hable directamente con el hipervisor. Linux lo hace con las interfaces propias de KVM. El Fisher-Price OS (Windows) solo habla un dialecto paravirtual, el de Hyper-V, así que KVM implementa ese dialecto y le dice al invitado que corre sobre un hipervisor compatible con Hyper-V. Cada pieza de ese dialecto se llama enlightenment.

Nada de esto está activo a menos que algo lo pida. La documentación de QEMU lo dice sin rodeos: «No Hyper-V enlightenments are enabled by default by either KVM or QEMU»¹. En Proxmox, quien lo pide es qemu-server, y solo lo pide cuando el tipo de SO es una de las entradas Microsoft Windows.

La diferencia se ve en cualquier host. Esta es una VM Linux en mi nodo 9.2, ostype: l26, tipo de CPU host:

# qm showcmd 101 --pretty | grep -- -cpu
  -cpu host,+kvm_pv_eoi,+kvm_pv_unhalt \

Dos flags de KVM para el manejo paravirtual de interrupciones y spinlocks propio de Linux, y ningún flag hv_. Correcto para Linux. Incorrecto para un invitado que solo entiende Hyper-V.

Lo que hace cada enlightenment, según las descripciones de QEMU¹:

El tipo de SO es el interruptor

La regla vive en una sola función, get_hyperv_enlightenments, en el CPUConfig.pm de qemu-server². Primero el tipo de SO se convierte en un número de versión: win11 pasa a ser 11, win10 pasa a ser 10, w2k8 y wvista pasan los dos a 6, y los tipos XP y 2003 pasan a 5. Linux, Other y todo lo demás pasan a 0.

Luego las compuertas se aplican en orden.

Leer una regla es una cosa. Ejecutarla es mejor. Así que cargué el CPUConfig.pm instalado en dos hosts 9.2, mi nodo AMD Ryzen para las filas AMD y un nodo Intel Celeron N5100 para las Intel, y llamé a esa función con cada combinación:

Ahí dentro hay tres cosas que conviene saber antes de acercarse a la GUI.

Un invitado UEFI con un tipo de SO anterior al 8.x no recibe nada. El código sale antes de tiempo cuando el firmware es OVMF y la versión está por debajo de 8. Un invitado 7/2008r2 que pasaste a UEFI ha perdido en silencio todos los enlightenments que tenía.

hv_evmcs quiere tres cosas a la vez. Un host Intel, el tipo de SO 11/2022/2025 y la versión de máquina 11.0+pve2 o posterior. Un invitado 10/2016/2019 no lo recibe nunca por defecto, por nueva que sea su versión de máquina.

El fabricante del host se lee cuando arranca la VM. La comprobación llama a read_cpuinfo en el nodo que hace el arranque, no en el sitio donde se creó la VM. En un clúster mixto Intel y AMD, la misma VM recibe hv_evmcs en un nodo y no en el otro, y se decide de nuevo en cada arranque en frío.

Las compuertas de versión de máquina más antiguas (2.3, 2.6, 2.12, 3.1) solo importan a las VMs ancladas a máquinas del pasado remoto de QEMU. Todo lo que crearías hoy las pasa.

Así que elige el tipo de SO más cercano al invitado, no el más nuevo de la lista. Un invitado 10/2016/2019 va en 10/2016/2019. La documentación de Proxmox da una segunda razón por la que el tipo importa más allá de estos flags: también fija cosas como si el RTC virtual va en hora local³.

Por qué tus VMs antiguas se quedan sin el arreglo de julio

Que hv_evmcs venga por defecto es nuevo. Llegó con qemu-server 9.2.0 el 15 de julio de 2026, para «mitigate guest freezes and 100% CPU usage seen on certain Intel CPUs with Windows guests that use Virtualization-Based Security (VBS)»⁴, y está atado a la versión de máquina 11.0+pve2.

Esa atadura es la trampa, porque Proxmox ancla la versión de máquina de toda VM con un tipo de SO Microsoft Windows en el momento de crearla. La documentación da el motivo: «Windows is sensitive to changes in the virtual hardware - even between cold boots»³. Es una decisión sensata. También significa que una VM creada en junio de 2026 está en 11.0+pve1 o anterior, y ahí se quedará hasta que alguien la mueva.

¿Alguien te la va a mover? No. El nuevo valor por defecto se aplica a las VMs nuevas y a las que subas a propósito, y a nada más.

Si tienes hosts Intel con invitados 11/2022/2025 con VBS activado, y alguno se ha congelado al 100 % de CPU, esto es lo primero que hay que comprobar:

qm config <vmid> | grep -E '^(ostype|machine):'

Un ostype: win11 con una línea machine: por debajo de pc-q35-11.0+pve2 necesita subir para recibir el arreglo. Subirla cambia el hardware virtual que ve el invitado, que es justo lo que el anclaje protege. Así que hazlo en una ventana de mantenimiento, con una copia de seguridad o un snapshot hecho antes, desde Hardware → Machine → Edit, marca Advanced y elige la versión.

Si la línea empieza por pc-i440fx-, la versión es el problema menor: ese invitado no debería estar en i440fx en absoluto, por los motivos de Usa siempre Q35, no i440fx, y Ponerlo, y demostrar que ha cogido más abajo lo cubre.

Otros dos valores por defecto relacionados llegaron en los mismos pocos meses, y conviene conocerlos ya que estás ahí. qemu-server 9.1.12 desactivó los flags cet-ibt y cet-ss para el tipo 11/2022/2025, porque con QEMU 11.0 y los kernels 7.x exponiéndolos, los invitados con VBS no arrancaban⁴. Y la 9.1.14 expuso la propiedad level de la CPU, que la documentación describe como «a known workaround for Hyper-V boot failures of Windows guests on recent Intel hosts when the CPU type is host or max»³.

El lado de QEMU, versión a versión

qemu-server construye la línea de comandos. pve-qemu-kvm es el QEMU que la ejecuta, y el arreglo de julio necesita los dos.

La versión de máquina 11.0+pve2 solo se puede elegir cuando hay instalado un binario de QEMU 11.0, porque qemu-server rechaza cualquier versión de máquina más nueva que el QEMU que encuentra en el host⁵. El +pve2 es el contador de revisiones del propio qemu-server, no de QEMU, así que cualquier compilación 11.0 lo cumple. El día que salió la 9.2.0, la pareja era esta:

¿Se asegurará apt de que tengas los dos? No. qemu-server 9.2.0 no declara nada más fuerte que pve-qemu-kvm (>= 7.1~)⁶, así que un nodo con QEMU retenido en 10.x acepta el nuevo qemu-server sin rechistar y luego no puede ofrecer la versión de máquina de la que depende el arreglo. Comprueba los dos, en cada nodo. Este es mi host 9.2 hoy, ya muy por delante de ambos:

# pveversion -v | grep -E '^(qemu-server|pve-qemu-kvm):'
pve-qemu-kvm: 11.0.3-4
qemu-server: 9.2.11

Cada versión de QEMU desde que Proxmox VE 9.0 salió con la 10.0.2⁷ ha traído arreglos propios para los invitados Fisher-Price OS (Windows). Estos son los que tocan al invitado, sacados del changelog del paquete de Proxmox⁸ y de los changelogs de QEMU upstream⁹:

QEMU 11.0 también rompió algo: empezó a exponer cet-ibt y cet-ss, que es lo que impedía arrancar a los invitados con VBS e hizo que qemu-server 9.1.12 los desactivara, como se ha visto arriba.

Los arreglos del agente de invitado en esas mismas versiones son otra historia. QEMU 10.1, 10.2 y 11.0 corrigieron cada una partes del manejo de VSS y de congelación del sistema de ficheros del agente, incluido el «Access denied Event ID 8194» que curó la 11.0⁹. Nada de eso llega con pve-qemu-kvm. El agente para ese invitado viene en la ISO de drivers virtio-win¹⁰, así que solo cambia cuando actualizas el agente dentro de la VM.

Los dos flags que puedes poner a mano

Proxmox no te deja añadir flags de CPU arbitrarios a una VM. En Hardware → Processors → Edit, marcas Advanced, y Extra CPU Flags ofrece una lista fija, definida en CPUFlags.pm¹¹. Dos entradas de esa lista son enlightenments, y son las dos que Proxmox no pone por defecto, o no ponía hasta julio.

Los dos pasaron a ser opcionales en qemu-server 6.0-6 el 23 de julio de 2019, descritos en el changelog como «sometimes problematic»⁴. hv-tlbflush sigue así siete años después. Eso da una buena pista de cuántas pruebas quiere antes de extenderlo por un clúster.

La nota de QEMU sobre hv-evmcs es que es solo Intel, y que «some virtualization features (e.g. Posted Interrupts) are disabled when hv-evmcs is enabled»¹. Activarlo a mano en un invitado que no hace virtualización anidada no te da nada y te cuesta eso.

Ponerlo, y demostrar que ha cogido

Para una VM nueva: Create VM → OS, pon Type en Microsoft Windows y Version en lo más parecido.

Para una existente: Options → OS Type → Edit, elige la versión, OK. Proxmox ancla la versión de máquina cuando cambias una VM existente a un tipo Microsoft Windows, igual que al crearla⁴, así que cuenta con que cambie también la línea machine: de la configuración.

Y ponla en q35. Un invitado con enlightenments no pinta nada en pc-i440fx. Es el chipset sin bus PCIe, y los motivos van mucho más allá del passthrough; están todos en Usa siempre Q35, no i440fx.

El asistente no te lo impide, y para la mayoría de los tipos Microsoft Windows te deja ahí. La propia documentación de Proxmox llama a Intel 440FX «the default»³, y los valores por defecto de SO de la GUI lo sustituyen para una sola entrada: 11/2022/2025 recibe machine: 'q35' y bios: 'ovmf'¹². Todos los demás tipos Microsoft Windows heredan los valores genéricos, que no fijan ninguna máquina. Así que un invitado 10/2016/2019 creado pulsando Next acaba en i440fx, con enlightenments y en el chipset equivocado a la vez.

Cámbialo en la pestaña System antes de terminar el asistente. Para una VM que ya existe, cambiar de chipset es un cambio mayor en el hardware virtual que subir la versión de máquina, así que valen las mismas reglas de ventana de mantenimiento y copia de seguridad, y el artículo sobre q35 cubre lo que hace el invitado al respecto.

Luego párala como es debido. Los enlightenments son argumentos de la línea de comandos de QEMU, y esa línea solo se construye cuando arranca el proceso de QEMU. Un reinicio desde dentro del invitado mantiene el mismo proceso, así que mantiene los flags viejos. Apaga, espera a stopped y luego Start.

Demuéstralo desde el host, porque es ahí donde está la respuesta:

qm showcmd <vmid> --pretty | grep -o "hv_[a-z_]*[=0-9a-fx]*" | sort -u

Eso imprime lo que qemu-server le pasará a QEMU en el próximo arranque. Un invitado 11/2022/2025 en 11.0+pve2 sobre Intel debería listar once: hv_evmcs, hv_ipi, hv_relaxed, hv_reset, hv_runtime, hv_spinlocks=0x1fff, hv_stimer, hv_synic, hv_time, hv_vapic y hv_vpindex. El mismo invitado sobre AMD lista diez. Un resultado vacío significa que el tipo de SO no es uno Microsoft Windows, o que es un tipo anterior al 8.x sobre UEFI.

Si un invitado no arranca tras el cambio, vuelve a poner el tipo de SO en Other durante un arranque para descartar o confirmar los enlightenments. Funciona sin ellos. Simplemente funciona peor.

Microcódigo: qué arregla y de dónde viene

El segundo valor por defecto está debajo del hipervisor, no encima.

El microcódigo de CPU es el firmware del fabricante para el propio procesador. Las actualizaciones corrigen vulnerabilidades de seguridad y fallos graves de la CPU, y la guía de administración de Proxmox deja claro lo que importa a quien le preocupe el coste en velocidad: «a patched microcode is usually still more performant than an unpatched microcode where the kernel itself has to do mitigations»¹³.

Puede venir de tres sitios, y son independientes.

La vía de la BIOS es la que Proxmox llama recomendada¹³. La carga temprana es la red de seguridad para cuando el fabricante de la placa ha dejado de sacar actualizaciones de BIOS, cosa que en cualquier equipo de unos pocos años suele haber pasado ya.

Esa tercera fila me sorprendió. Proxmox lleva en su propio repositorio un amd64-microcode más nuevo que el que tiene Debian en trixie¹⁴, con la misma prioridad de pin, así que apt elige el de Proxmox. En un host AMD con el repositorio de Proxmox configurado, esa es la versión que acabarás ejecutando, y como muestra la siguiente sección, es la versión que importa.

La carga temprana es lo que este post configura. El microcódigo va al initramfs y el kernel lo aplica al principio del todo del arranque, antes de que corra nada más.

La carga tardía lo aplica a un sistema en marcha. La documentación del propio kernel tiene una sección titulada «Why is late loading dangerous?» y desde la 5.19 no viene activada por defecto¹⁵. Debian también la bloquea. Este es el fichero de mi host, tal cual:

# cat /etc/modprobe.d/amd64-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

Déjalo estar. El host de arriba lo tiene puesto y aun así muestra una actualización temprana correcta, así que no estorba a nada.

Cualquiera de las dos vías necesita un reinicio. No hay forma de evitarlo.

Y es solo x86. La guía de Proxmox lo dice claramente: «There is no equivalent operating-system-level microcode package for arm64»¹³.

Por qué un host actualizado no tiene ninguno

El «non-free» de non-free-firmware va de la licencia, no de dinero ni de una suscripción de Proxmox. La wiki de Debian lo explica: la parte del kernel es software libre, pero los datos de actualización del fabricante son «opaque», «and its contents are unknown to Debian»¹⁶. Por eso vive en su propio componente, y por eso un sistema Debian no lo recibe a menos que el componente esté activado.

El instalador de Proxmox VE 9.0 lo activa. Las notas de la versión dicen que la ISO va a «Install the microcode package matching the current platform», y que «installations now have the non-free-firmware repository enabled»⁷. Una actualización no hace ninguna de las dos cosas, porque conserva las líneas de repositorio que tenías en la 8.x.

El comprobador sí lo señala, y más alto de lo que esperaba. Esto es en mi nodo Intel, que subió desde la 8.x:

# pve8to9 | grep -i -B1 -A2 microcode
PASS: Legacy file '/etc/sysctl.conf' is not present.
INFO: Checking if matching CPU microcode package is installed.
FAIL: unable to determine installed intel-microcode version.
WARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
	apt install intel-microcode
SKIP: NOTE: Expensive checks, like CT cgroupv2 compat, not performed without '--full' parameter

El FAIL es un efecto secundario: la consulta de versión registra un fallo para cualquier paquete que no esté instalado, antes de que la comprobación del microcódigo llegue a su propio aviso¹⁷. En cualquier caso, pve8to9 es un comprobador, no una barrera. No ejecuta la actualización y no puede pararla, así que la actualización pasa por encima sin pararse.

¿Importa eso en la práctica? Estos son dos casos en que sí, y el primero es mío.

Ese nodo Intel es un Celeron N5100. Su lista de fuentes ya llevaba non-free-firmware, así que el paquete estaba a un comando de distancia, y hasta el 27 de octubre de 2026 nadie lo había ejecutado. El kernel se dio cuenta aunque nadie más lo hiciera:

# dmesg | grep -i microcode
[    0.000000] x86/CPU: Running old microcode
[    0.497219] microcode: Current revision: 0x0000001d
# lscpu | grep -i 'old microcode'
Vulnerability Old microcode:             Vulnerable

El kernel guarda «a table of released microcode», y una CPU que arrancó con algo más antiguo «will say “Vulnerable”»¹⁸. ¿Cómo de antiguo es antiguo? Las notas de versión de Intel lo responden para este chip¹⁹:

La BIOS es la versión 5.19, fechada el 8 de noviembre de 2022, y todavía carga el primer microcódigo que Intel publicó para el chip, con dos más nuevos ya disponibles cuando se compiló. Es justo el caso para el que existe la vía de carga temprana: cuatro actualizaciones esperando en un paquete que el host ya podía ver. Lo instalé mientras escribía esto, y lo que hizo está en Activarlo, porque enseña una pega.

El segundo caso es el de AMD. Los Zen 5 tienen un fallo en la instrucción RDSEED²⁰. Las notas de la versión 9.1 de Proxmox recogen lo que pasa después: los kernels desde el 6.17.9 en adelante, «without active microcode update will disable the RDSEED32 CPU-bit, and will fail to run Qemu guests with a CPU type that exposes that bit (for example EPYC or EPYC-v4)»²¹. El arreglo es amd64-microcode 3.20251202.1~bpo13+1 o posterior, que es la versión del repositorio de Proxmox y no la de Debian.

Dentro de esa trampa hay otra. En placas Zen 5 cuya BIOS es anterior al arreglo de la vulnerabilidad Entrysign de AMD, el kernel rechaza el microcódigo nuevo y registra No sha256 digest for patch ID, y el consejo de Proxmox es actualizar la BIOS²¹. Así que en ese hardware la vía del sistema operativo solo funciona cuando el fabricante de la placa ha hecho su parte.

Activarlo

Apunta primero dónde estás. En el host, como root:

pveversion
grep -m1 vendor_id /proc/cpuinfo                 # GenuineIntel or AuthenticAMD
grep microcode /proc/cpuinfo | uniq              # revision running now
dpkg -l intel-microcode amd64-microcode 2>/dev/null | grep ^ii
dmesg | grep -i microcode
lscpu > /root/lscpu-before.txt                   # vulnerabilities and mitigations

Si dpkg ya muestra el paquete que corresponde como ii, el host está listo y puedes saltar a comprobar el resultado.

Activa el componente. El apt de trixie prefiere el formato deb822 .sources, y la guía de actualización de Proxmox remite a apt modernize-sources para convertir los viejos ficheros de una línea, guardando los originales como .bak²². Luego añade non-free-firmware a la línea Components: de la estrofa principal y de la de seguridad en /etc/apt/sources.list.d/debian.sources. Este es el fichero de mi host, que salió del instalador:

Types: deb
URIs: http://deb.debian.org/debian/
Suites: trixie trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/debian-security/
Suites: trixie-security
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Las dos estrofas, porque Debian distribuye microcódigo a stable por las dos vías. El archivo de seguridad lleva intel-microcode 3.20250812.1~deb13u1 mientras que el principal ya ha pasado a 3.20251111.1~deb13u1²³, y tú quieres el que sea más nuevo.

Instala el que corresponde a la CPU.

apt update
apt install intel-microcode     # Intel
apt install amd64-microcode     # AMD

Solo el de tu fabricante. A partir de ahí el microcódigo nuevo llega con las ejecuciones normales de apt full-upgrade, y cada versión nueva necesita un reinicio como la primera.

Instalarlo reconstruye el initramfs, porque ahí es donde tiene que vivir el microcódigo temprano. El kernel lo lee de un archivo sin comprimir al principio del initrd, como kernel/x86/microcode/GenuineIntel.bin o AuthenticAMD.bin¹⁵, y el script de instalación del paquete dispara el trigger del initramfs para ponerlo ahí²⁴. Este es mi nodo Intel recibiendo el paquete mientras escribía este post:

# grep -A6 'Setting up intel-microcode' /var/log/apt/term.log
Setting up intel-microcode (3.20251111.1~deb13u1) ...
intel-microcode: microcode will be updated at next boot
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for initramfs-tools (0.148.4) ...
update-initramfs: Generating /boot/initrd.img-7.0.14-24-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..

zz-proxmox-boot es el hook de Proxmox. En un host cuyas particiones EFI mantiene proxmox-boot-tool, copia ahí la imagen nueva; este no tiene ninguna que sincronizar.

Ahora fíjate en qué imagen generó. Sin un kernel indicado, update-initramfs -u reconstruye solo la más nueva: «The default is the latest kernel version»²⁵. El mismo nodo, justo después:

# uname -r
7.0.14-23-pve
# for f in /boot/initrd.img-*; do echo "$f: $(lsinitramfs $f 2>/dev/null | grep -c GenuineIntel.bin)"; done
/boot/initrd.img-7.0.12-1-pve: 0
/boot/initrd.img-7.0.14-11-pve: 0
/boot/initrd.img-7.0.14-12-pve: 0
/boot/initrd.img-7.0.14-19-pve: 0
/boot/initrd.img-7.0.14-23-pve: 0
/boot/initrd.img-7.0.14-24-pve: 1
/boot/initrd.img-7.0.14-8-pve: 0

Una imagen de siete lleva el microcódigo, y no es la que está ejecutando el host.

Así que reconstruye todas las imágenes después de instalar, y otra vez tras cada actualización del microcódigo, porque cada una dispara la misma reconstrucción solo del núcleo más reciente. Luego vuelve a ejecutar el bucle de arriba para demostrarlo:

update-initramfs -u -k all

Reinicia y comprueba. Este es mi host AMD 9.2 después de poner el paquete del repositorio de Proxmox:

# grep microcode /proc/cpuinfo | uniq
microcode	: 0xa500012
# dmesg | grep -i microcode
[    0.587928] microcode: Current revision: 0x0a500012
[    0.587930] microcode: Updated early from: 0x0a50000d

Updated early from es la línea que lo demuestra. La guía de administración de Proxmox todavía muestra la redacción antigua, microcode updated early to revision¹³; el kernel actual imprime las dos líneas de arriba²⁶. Cualquiera de las dos formas significa que ha funcionado.

Que no salga esa línea no es un fallo por sí solo. Solo aparece cuando el paquete trae algo más nuevo que la revisión integrada de la CPU y que la que cargó la BIOS. Un paquete cubre un montón de modelos de CPU, y la guía tiene razón en que su fecha no te dice cuándo recibió algo tu modelo por última vez¹³.

Extenderlo por un clúster

El cambio de repositorio y la instalación pueden ir en todos los nodos a la vez. No cambia nada hasta un reinicio. Los reinicios van de nodo en nodo, y cada nodo está sano antes de que caiga el siguiente.

El modo de mantenimiento de HA apunta de dónde venía cada invitado HA y lo devuelve en cuanto el nodo sale del mantenimiento²⁷. Los invitados sin HA son cosa tuya.

Sobre noout hay opiniones distintas, y las dos partes tienen su razón. Ceph marca rápido como down un OSD que calla, pero solo lo marca out pasado mon_osd_down_out_interval, que por defecto son diez minutos²⁸, y es el out lo que dispara el rebalanceo. Un reinicio normal vuelve con mucho margen. Un servidor con un POST largo, un aviso del firmware o una controladora RAID lenta quizá no. Poner noout evita que un reinicio lento se convierta en un rebalanceo. El precio es acordarse de quitarlo, y un noout olvidado esconde más adelante un fallo de verdad.

Haz el clúster entero en una sola ventana. Nodos con revisiones de microcódigo distintas es justo la situación en que un invitado con tipo de CPU host, que ve directamente las funciones de la CPU física, puede migrar en caliente a un nodo que informa de un conjunto diferente.

Cuando una actualización de microcódigo sale mal

Es raro, pero pasa, y la guía de Proxmox lo cubre como es debido¹³.

Para el arranque puntual: menú de GRUB (mantén Mayús si está oculto), E sobre la entrada de Proxmox, añade dis_ucode_ldr a la línea que empieza por linux, y luego Ctrl+X. Un host con systemd-boot en vez de GRUB está cubierto en el capítulo del gestor de arranque de la guía de administración.

La vuelta atrás, en Intel:

apt list -a intel-microcode               # what versions exist
apt install intel-microcode=<version>     # pick the earlier one
apt-mark hold intel-microcode             # stop the next upgrade undoing it
reboot

En AMD, cambia a amd64-microcode. Vuelve atrás de versión, nunca hagas purge.

Un valor por defecto es una promesa a quien tomó el camino esperado

Ninguna de las dos cosas es un bug. Proxmox hizo lo sensato las dos veces: activar la función donde es seguro, dejarla apagada donde quizá no lo sea, y anclar el hardware virtual con el que el invitado es quisquilloso. El instalador se arregló, el comprobador de la actualización lo señala, el changelog dice qué cambió y cuándo. Proxmox ha hecho su parte.

Pero un valor por defecto es una promesa hecha a quien hizo las cosas como el fabricante esperaba. Instalación nueva, tipo de SO correcto, VM creada después de julio. Cualquiera cuyo parque tenga historia, y eso es todo el que tenga algo real en marcha, queda en parte fuera de esa promesa, y el hueco no se anuncia. Aparece como un invitado que va algo lento, una congelación de VBS que nadie relaciona con una versión de máquina, o un nodo Zen 5 donde los invitados EPYC no arrancan tras una actualización del kernel.

Las notas de la versión describen lo que recibe una instalación nueva. No dicen ni pío de lo que tus hosts están ejecutando de verdad, y son preguntas distintas. La única forma de responder a la segunda es ir y mirar: qm showcmd en los invitados, dmesg en los hosts, la línea de máquina en la configuración. Nada de eso lleva más de un minuto por máquina.

Ese minuto es el trabajo. Proxmox te da las herramientas para comprobarlo, y como tal el hueco entre lo que suponías y lo que está corriendo te toca cerrarlo a ti, no a ellos.