La VM de Proxmox no arranca tras cambiar el tipo de CPU: pasos de recuperación que funcionan

enero 27, 2026 • febrero 3, 2026 • Lectura: 25 min • Views: 6

¿Te fue útil?

Cambiaste el tipo de CPU en una VM de Proxmox porque querías rendimiento, coherencia para migración o seguiste una publicación de foro bienintencionada. Ahora la VM no arranca, Proxmox muestra “QEMU exited with code 1” y te quedas mirando una carga de trabajo detenida que funcionaba perfectamente hace cinco minutos.

Este fallo es habitual, normalmente reparable en minutos y, a veces, una señal de que has vivido al límite durante meses. Recuperemos la VM con seguridad, expliquemos qué falló realmente y pongámonos en posición para cambiar tipos de CPU sin jugar a la ruleta la próxima vez.

Guía rápida de diagnóstico

Si solo tienes diez minutos antes de que alguien pregunte por qué el panel aparece en rojo, haz esto en orden. El objetivo es identificar si tratas con un problema puro de modelo de CPU en QEMU, una reacción del SO invitado o una incompatibilidad hardware/anfitrión.

Primero: lee el error real de QEMU, no la notificación de la interfaz

Revisa el registro de tareas y el journal del intento de arranque de la VM.
Busca específicamente frases como unsupported CPUID, host doesn’t support requested feature, invalid CPU model o kvm: failed to init.

Segundo: confirma la configuración actual de la VM frente a la anterior

Verifica la línea cpu: y cualquier sobrescritura args:.
Si tienes copias de seguridad, compara la configuración actual con la última conocida como buena.

Tercero: decide si la solución es “revertir el tipo de CPU” o “cambiar a una línea base más segura”

Si esta VM debe arrancar ahora: revierte al tipo de CPU anterior (o a host si funcionaba antes).
Si esta VM debe migrar entre nodos: elige una base como x86-64-v2/x86-64-v3 (donde esté soportado) o un modelo nombrado que exista en todos tus nodos.

Cuarto: si arranca, valida la vista del CPU dentro del invitado y la estabilidad

Para Windows: comprueba implicaciones en activación/licencias y verifica que los servicios críticos se inicien.
Para Linux: revisa dmesg en busca de advertencias sobre características de CPU, mensajes de microcode y cambios de clocksource.

Una verdad operativa: una VM que no arranca suele ser un desajuste de configuración. Una VM que arranca pero se comporta raro suele deberse a una regresión en características de CPU, un cambio en timer/clocksource o expectativas de controladores del invitado.

Qué se rompió realmente al cambiar el tipo de CPU

En Proxmox, el ajuste “tipo de CPU” no es cosmético. Controla qué modelo de CPU virtual anuncia QEMU al invitado y qué se le pide a KVM acelerar. Eso incluye:

Banderas de CPUID (SSE4.2, AVX, AVX2, AES-NI, BMI, FMA, etc.).
Nivel del conjunto de instrucciones y peculiaridades (algunos modelos implican grupos de banderas).
Exposición de topología (sockets/cores/threads) y, ocasionalmente, comportamiento de caché/tiempos.
Compatibilidad de migración entre hosts: el modelo de CPU puede ser un contrato que debe cumplirse en todos los nodos donde la VM pueda aterrizar.

Cuando eliges host, QEMU intenta exponer una CPU que coincida estrechamente con la del host, habilitando lo que la CPU física soporte. Excelente para rendimiento. También excelente para complicarte la vida si luego mueves la VM a un host con menos características o diferente microarquitectura.

Cuando eliges un modelo nombrado (por ejemplo, Skylake-Server, EPYC, Broadwell), QEMU expone un conjunto curado de banderas. Esto puede mejorar la compatibilidad de migración, pero también puede fallar estrepitosamente si:

La CPU del host no soporta una de las características solicitadas.
La versión de QEMU en el nodo no reconoce el nombre del modelo.
La VM tiene una línea args: explícita forzando banderas que entran en conflicto con el modelo elegido.
Estás cruzando Intel ↔ AMD y el modelo asume comportamientos específicos del proveedor.

Y a veces la VM sí arranca, pero el SO invitado protesta después. Windows puede decidir que está en “nuevo hardware” y Linux puede cambiar el comportamiento del clocksource o desactivar ciertas rutas rápidas del kernel.

Chequeo de realidad seco-gracioso (broma #1): Los cambios de tipo de CPU son como “refactors rápidos”. La palabra “rápido” es más para apoyo emocional.

Hechos interesantes y contexto histórico

Estos no son datos para trivia por trivia. Cada uno explica por qué los cambios de tipo de CPU pueden romper una VM previamente estable.

CPUID ha sido un campo minado de compatibilidad desde los años 90. Los invitados no solo “usan lo que existe”; toman decisiones basadas en banderas reportadas y en el ID del proveedor.
KVM no es un emulador ante todo; es un acelerador. Si solicitas características de CPU que el host no puede proporcionar, KVM se niega —rápido y sin disculpas.
Los nombres de modelos de CPU en QEMU no son eternos. Los modelos y alias evolucionan entre versiones de QEMU; las actualizaciones de Proxmox pueden añadir modelos, eliminar otros o cambiar valores por defecto.
La migración en vivo fue el motor para las líneas base de CPU. La razón por la que existen tipos “genéricos” es hacer práctico “mover esta VM a cualquier parte”.
La virtualización de Intel y AMD difiere en comportamientos límite. Incluso cuando ambos soportan los mismos conjuntos de instrucciones, las características específicas del proveedor y las peculiaridades del microcódigo importan para invitados e hipervisores.
La era Spectre/Meltdown impactó la virtualización. El microcódigo y las mitigaciones del kernel cambiaron el rendimiento y, a veces, alteraron las características expuestas; los clusters vieron CPUs “idénticas” comportarse distinto tras parches.
La activación de Windows puede tratar cambios de identidad de CPU/placa como un cambio de hardware. Cambiar el modelo de CPU puede ser suficiente para activar comprobaciones de licencia según la edición y el método de activación.
La virtualización anidada es extra sensible. Si el invitado ejecuta un hipervisor, suele necesitar banderas VMX/SVM específicas; los cambios de modelo de CPU pueden eliminarlas.

Tareas prácticas de recuperación (comandos, salidas, decisiones)

A continuación tienes tareas prácticas que puedes ejecutar en el nodo Proxmox. Cada una incluye: el comando, qué significa una salida típica y qué decisión tomar desde ahí. Hazlas en orden hasta que tengas una VM arrancada o una causa raíz clara.

Tarea 1: Identificar el evento de fallo de arranque en el journal

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "30 min ago" | tail -n 80
Dec 26 11:02:15 pve01 pvedaemon[2217]: starting task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
Dec 26 11:02:15 pve01 pvedaemon[2217]: VM 105 start failed: command '/usr/bin/kvm -id 105 ... -cpu Skylake-Server,...' failed: exit code 1
Dec 26 11:02:15 pve01 pvedaemon[2217]: end task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: VM 105 start failed: exit code 1

Qué significa: Has confirmado que es una falla de inicio de QEMU/KVM, no un fallo del SO invitado después del arranque.

Decisión: Ve a buscar el error detallado de QEMU (Tarea 2). No adivines.

Tarea 2: Extraer el error detallado de QEMU del registro de la tarea

cr0x@server:~$ cat /var/log/pve/tasks/active | head
UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
cr0x@server:~$ cat /var/log/pve/tasks/UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: | tail -n 60
kvm: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
TASK ERROR: start failed: QEMU exited with code 1

Qué significa: El modelo de CPU seleccionado (o banderas personalizadas) solicita VMX, pero el host no puede proporcionarlo (o está deshabilitado).

Decisión: Comprueba el soporte de virtualización de la CPU del host y la configuración del BIOS (Tarea 3 y Tarea 4). Si esta VM no necesita virtualización anidada, elimina ese requisito en las banderas de CPU (tareas posteriores).

Tarea 3: Verificar que KVM esté cargado y que la virtualización esté disponible

cr0x@server:~$ lsmod | egrep 'kvm|vhost' | head
kvm_intel             385024  0
kvm                  1200128  1 kvm_intel
vhost_net              36864  0
vhost                  53248  1 vhost_net

Qué significa: Los módulos KVM están cargados. Eso es necesario pero no suficiente.

Decisión: Confirma las banderas de CPU expuestas por el host (Tarea 4).

Tarea 4: Confirmar que las banderas del CPU del host incluyan lo que la VM solicita

cr0x@server:~$ lscpu | egrep 'Vendor ID|Model name|Flags|Virtualization' -A1
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Virtualization:      VT-x
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... vmx ... avx avx2 ...

Qué significa: VT-x (bandera vmx) existe. Si QEMU dijo que VMX no está soportado, o el BIOS lo desactivó, el kernel lo está enmascarando, o no estás en el nodo que crees.

Decisión: Si Virtualization está en blanco o falta la bandera, arregla la configuración del BIOS/firmware. Si está presente, la configuración de la VM probablemente fuerza algo inconsistente (Tarea 6 y Tarea 7).

Tarea 5: Inspeccionar la configuración actual de la VM para tipo de CPU y banderas forzadas

cr0x@server:~$ qm config 105
boot: order=scsi0;net0
cores: 8
cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear
memory: 16384
name: payroll-app01
net0: virtio=DE:AD:BE:EF:10:05,bridge=vmbr0
scsi0: local-lvm:vm-105-disk-0,discard=on,iothread=1
scsihw: virtio-scsi-pci

Qué significa: El modelo de CPU está establecido explícitamente en Skylake-Server con banderas adicionales. Si el host es más antiguo o AMD, esto puede fallar.

Decisión: Si cambiaste esto recientemente y la VM solía arrancar, revierte al tipo de CPU anterior (Tarea 8). Si necesitas compatibilidad de migración, elige una base más adelante.

Tarea 6: Buscar sobrescrituras ocultas en `args:`

cr0x@server:~$ grep -nE '^(cpu:|args:|machine:|bios:|ostype:)' /etc/pve/qemu-server/105.conf
3:cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear

Qué significa: No hay args: inesperadas aquí. Bien. Si sí ves una línea args:, considérala sospechosa hasta que se demuestre lo contrario.

Decisión: Si args: está presente e incluye -cpu o -machine, elimínala/ajústala; la interfaz de Proxmox no te librará de tu yo del pasado.

Tarea 7: Validar que el nombre del modelo de CPU sea reconocido por tu compilación de QEMU

cr0x@server:~$ /usr/bin/qemu-system-x86_64 -cpu help | egrep -i 'skylake|broadwell|epyc|x86-64' | head -n 20
x86-64-v2
x86-64-v3
Broadwell
Skylake-Server
EPYC
EPYC-Rome

Qué significa: El modelo existe en este nodo. Si no existiera, QEMU fallaría inmediatamente con “invalid CPU model”.

Decisión: Si el modelo falta en algunos nodos del clúster, tienes un problema de desalineación de versiones. Alinea las versiones de Proxmox/QEMU entre nodos o estandariza un modelo disponible en todas partes.

Tarea 8: Revertir el tipo de CPU al último conocido como bueno (restauración más rápida)

cr0x@server:~$ cp -a /etc/pve/qemu-server/105.conf /root/105.conf.before-revert
cr0x@server:~$ qm set 105 --cpu host
update VM 105: -cpu host
cr0x@server:~$ qm start 105

Qué significa: Estás revirtiendo a host, que normalmente arranca si la VM ya funcionaba en este nodo.

Decisión: Si esto inicia, corta la hemorragia. Luego decide si realmente necesitas otro modelo de CPU (sección posterior). Si aún falla, el problema no es sólo “nombre de modelo”; puede ser banderas, tipo de máquina o disponibilidad de virtualización de hardware.

Tarea 9: Si `host` falla, prueba una línea base genérica más segura

cr0x@server:~$ qm stop 105
stopping VM 105 (timeout = 60 seconds)
cr0x@server:~$ qm set 105 --cpu x86-64-v2
update VM 105: -cpu x86-64-v2
cr0x@server:~$ qm start 105

Qué significa: Estás pidiendo un conjunto conservador de características de CPU que tiende a funcionar entre muchos hosts modernos.

Decisión: Si esto arranca, probablemente tenías una característica no soportada en el modelo antiguo o en las banderas. Mantén x86-64-v2 (o v3 si el clúster lo soporta) como línea base del clúster.

Tarea 10: Confirmar que el proceso de la VM existe y usa aceleración KVM

cr0x@server:~$ pgrep -a -f 'kvm.*-id 105' | head -n 1
24788 /usr/bin/kvm -id 105 -name payroll-app01 ...
cr0x@server:~$ ps -o pid,comm,%cpu,%mem,args -p 24788
  PID COMMAND         %CPU %MEM COMMAND
24788 kvm              8.2  4.1 /usr/bin/kvm -id 105 -name payroll-app01 ...

Qué significa: La VM realmente arrancó y se está ejecutando como un proceso QEMU/KVM.

Decisión: Pasa de “el hipervisor puede arrancarla” a “el invitado está sano”. Si la VM sigue sin ser accesible, depura dentro del invitado (consola, red, servicios).

Tarea 11: Revisar la línea de comando de QEMU para la definición efectiva del CPU

cr0x@server:~$ qm showcmd 105 --pretty | sed -n '1,120p'
/usr/bin/kvm \
  -id 105 \
  -name payroll-app01,debug-threads=on \
  -no-shutdown \
  -chardev socket,id=qmp,path=/var/run/qemu-server/105.qmp,server=on,wait=off \
  -mon chardev=qmp,mode=control \
  -machine type=pc-q35-8.1+pve0 \
  -cpu x86-64-v2 \
  -smp 8,sockets=1,cores=8,maxcpus=8 \
  -m 16384 \
  ...

Qué significa: Esta es la única fuente de verdad para lo que QEMU está ejecutando realmente (después de que Proxmox transforme la configuración).

Decisión: Si ves un -cpu diferente al esperado, tienes entradas de configuración en conflicto o una sobrescritura args:.

Tarea 12: Validar la compatibilidad de características de CPU del clúster (realidad de migración)

cr0x@server:~$ pvesh get /nodes --output-format json-pretty
[
  {
    "node": "pve01",
    "status": "online"
  },
  {
    "node": "pve02",
    "status": "online"
  }
]
cr0x@server:~$ for n in pve01 pve02; do echo "== $n =="; ssh $n "lscpu | egrep 'Vendor ID|Model name|Flags' -A1 | head -n 6"; done
== pve01 ==
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Flags:               ... avx avx2 vmx ...
== pve02 ==
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
Flags:               ... avx avx2 vmx ...

Qué significa: Los nodos parecen similares, pero no idénticos. Pequeñas diferencias importan: un stepping distinto, un microcódigo distinto, una configuración de BIOS distinta y de repente una bandera desaparece.

Decisión: Si esperas migración, elige un modelo de CPU base soportado por todos los nodos. “Funciona en mi nodo” no es una estrategia.

Tarea 13: Revisar microcode y mensajes del kernel si las características “deberían existir” pero no aparecen

cr0x@server:~$ dmesg | egrep -i 'microcode|kvm|vmx|svm' | tail -n 30
[    0.812345] microcode: microcode updated early to revision 0x2006e04, date = 2023-10-12
[    6.112233] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
[    6.112455] kvm_intel: enabling virtualization on CPU0

Qué significa: El microcode y la inicialización de KVM son visibles. Si KVM se queja de virtualización deshabilitada, ese es tu indicio claro.

Decisión: Si la virtualización está deshabilitada a nivel de plataforma, arregla el BIOS y reinicia el nodo. No sigas “trabajando alrededor” de la falta de VMX/SVM.

Tarea 14: Si Windows no arranca tras el cambio de CPU, verifica bucle de arranque vs. fallo del hipervisor

cr0x@server:~$ qm terminal 105
starting serial terminal on interface serial0 (press Ctrl+O to exit)

Qué significa: Una terminal serial es una forma rápida de ver problemas tempranos de arranque en Linux; para Windows es menos útil a menos que hayas configurado depuración serial. Si tienes consola VGA en la GUI, úsa esa.

Decisión: Si la VM arranca pero se reinicia inmediatamente, ya pasaste la falla de inicio por modelo de CPU y estás en comportamiento del invitado. Mantén el hipervisor estable y depura el SO invitado por separado.

Tarea 15: Restaurar un archivo de configuración conocido como bueno si necesitas un rollback instantáneo

cr0x@server:~$ ls -l /root/105.conf.*
-rw-r--r-- 1 root root 512 Dec 26 11:05 /root/105.conf.before-revert
cr0x@server:~$ cp -a /root/105.conf.before-revert /etc/pve/qemu-server/105.conf
cr0x@server:~$ qm start 105

Qué significa: Estás sobrescribiendo lo que la UI hizo y volviendo a una instantánea de configuración guardada.

Decisión: Si esto lo arregla, trata el cambio previo de CPU como la causa raíz y procede a un recambio controlado con pruebas, no con intuiciones.

Tarea 16: Verificar que no estás luchando contra una incompatibilidad de tipo de máquina introducida por ediciones “útiles”

cr0x@server:~$ qm config 105 | egrep '^(machine:|bios:|efidisk0:|ostype:)'
machine: pc-q35-8.1+pve0
ostype: l26

Qué significa: El tipo de máquina es Q35. Algunos cambios de modelo de CPU coinciden con un cambio de tipo de máquina (ediciones manuales, guías antiguas). Esa combinación puede alterar la exposición de dispositivos y el arranque del invitado.

Decisión: Si cambiaste el tipo de máquina al mismo tiempo, reviértelo también. Cambia una variable a la vez, a menos que disfrutes los errores no forzados.

Chequeo de realidad seco-gracioso (broma #2): Si cambiaste tipo de CPU, tipo de máquina y modo BIOS en una sola edición, no “optimizaste”. Creaste una novela de misterio.

Errores comunes: síntoma → causa raíz → solución

Esta sección es deliberadamente directa. Son los patrones que siguen apareciendo en producción.

1) Síntoma: “QEMU exited with code 1” + “host doesn’t support requested feature”

Causa raíz: El modelo de CPU seleccionado o las banderas incluyen características ausentes en el host (o deshabilitadas en BIOS).
Solución: Revierte a host o a una base inferior como x86-64-v2. Si la característica faltante es VMX/SVM, arregla la configuración de virtualización en BIOS y reinicia el host.

2) Síntoma: “invalid CPU model” tras seleccionar un CPU nombrado

Causa raíz: La compilación de QEMU en ese nodo no conoce el nombre del modelo (desajuste de versión, conjunto de paquetes distinto o nodo Proxmox antiguo).
Solución: Usa /usr/bin/qemu-system-x86_64 -cpu help para elegir un modelo disponible. Estandariza las versiones de Proxmox/QEMU en el clúster.

3) Síntoma: La VM arranca en el nodo A, se niega a arrancar tras migrar al nodo B

Causa raíz: Tipo de CPU en host o un modelo demasiado moderno; el nodo B carece de las banderas requeridas.
Solución: Elige un modelo de CPU base del clúster soportado en todos los nodos. Aplícalo a la VM antes de migrar (ventana de mantenimiento planificada si el invitado es sensible).

4) Síntoma: Linux arranca, pero el rendimiento cae tras cambiar el tipo de CPU

Causa raíz: Eliminaste AVX/AVX2/AES u otras aceleraciones que la carga usaba (cripto, compresión, JVM, checksums de base de datos). O el invitado cambió el comportamiento del clocksource.
Solución: Compara las banderas de CPU antes/después. Selecciona una base que mantenga las características necesarias y siga siendo migrable. Valida clocksource y mensajes del kernel.

5) Síntoma: Windows arranca, pero la activación/licencias falla

Causa raíz: Windows percibe un cambio de identidad de hardware (los cambios de modelo/topología de CPU pueden contribuir).
Solución: Prefiere modelos de CPU estables a largo plazo. Si debes cambiar, hazlo una vez, documenta y espera flujos de activación según tu método de licenciamiento.

6) Síntoma: La virtualización anidada dejó de funcionar

Causa raíz: El cambio de modelo de CPU eliminó la exposición de vmx (Intel) o svm (AMD) al invitado.
Solución: Elige un modelo de CPU que incluya extensiones de virtualización y confirma que el BIOS del host las soporte. Evita manipular banderas al azar; prueba cargas anidadas explícitamente.

7) Síntoma: “KVM: entry failed” o errores de inicialización relacionados con KVM

Causa raíz: Restricciones del kernel/KVM del host, peculiaridades de microcode o combinación incompatible de banderas de CPU y tipo de máquina.
Solución: Elimina banderas personalizadas y revierte a un modelo de CPU conocido como bueno. Si el host cambió recientemente kernel/microcode, considera alinear nodos y reiniciar para una base consistente.

8) Síntoma: La VM solo arranca después de quitar una sola bandera de “mitigación de seguridad”

Causa raíz: Copiaste un conjunto de banderas de CPU de una generación diferente. Algunas banderas de mitigación mapean a capacidades y MSRs específicos que pueden no existir en todas partes.
Solución: Deja de habilitar mitigaciones manualmente a menos que sepas exactamente qué hacen. Usa modelos de CPU soportados y deja que QEMU/KVM maneje valores por defecto sensatos para tus versiones.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente provocado por una suposición errónea

Una empresa mediana ejecutaba un clúster Proxmox de dos nodos que “obviamente” tenía las mismas CPUs. Compras había pedido dos servidores al mismo proveedor en el mismo trimestre. Las fichas técnicas coincidían. El equipo puso la mayoría de las VMs de producción con cpu: host para máximo rendimiento.

Durante un reinicio de rutina de un host, varias VMs no arrancaron en el nodo superviviente. El error parecía una falla genérica de QEMU a primera vista. Bajo presión, el equipo persiguió fantasmas de almacenamiento y red—porque eso es lo que suele fallar en su mundo.

La causa raíz: un nodo tenía un stepping de CPU ligeramente más nuevo y un microcódigo distinto, exponiendo un par de banderas que el otro nodo no tenía. Cuando las VMs aterrizaron en el nodo más antiguo, KVM rechazó el conjunto de CPUID solicitado. La suposición no fue “estos servidores son idénticos.” Fue “idénticos es suficientemente cercano.” No lo es.

Se recuperaron cambiando las VMs afectadas a un modelo de CPU conservador que ambos nodos soportaban, luego programaron un inventario de hardware y una pasarela de estandarización. La interrupción no fue dramática. Fue peor: fue evitable y aburrida.

La corrección duradera fue cultural: cualquier cambio que afecte la compatibilidad de migración ahora requiere verificar que el modelo de CPU exista y sea compatible entre nodos antes de la ventana de mantenimiento.

Micro-historia 2: La optimización que salió mal

Un equipo de plataforma interno alojaba workers de compilación y runners de CI en VMs Proxmox. Perseguían tiempos de compilación más rápidos, así que cambiaron el tipo de CPU de un modelo base a host y añadieron banderas extra para AES y AVX2 “por si acaso.” El rendimiento mejoró en el nodo principal.

Luego un nodo entró en mantenimiento y el scheduler movió VMs. Algunos invitados arrancaron, otros no. Los que arrancaron producían fallos de compilación extraños e irreproducibles. Ese es el tipo de bug que hace a los ingenieros cuestionar su carrera.

El problema no era “AVX2 es malo.” El problema era la heterogeneidad: un nodo soportaba un conjunto de características y comportamiento microarquitectónico que el otro no, y los runners no estaban fijados. El sistema de builds terminó con una flota donde a veces los binarios se construían bajo diferentes capacidades de CPU, y las pruebas se comportaban distinto bajo diferentes temporizaciones y rutas de aceleración cripto.

Revirtieron a un tipo de CPU base para los runners, y solo habilitaron host para cargas de alto rendimiento fijadas y no migrables con reglas de colocación explícitas. El equipo además dejó de espolvorear banderas de CPU como sal. Si no tienes medición y plan de rollback, no estás optimizando—estás apostando.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera ejecutaba VMs críticas de Windows en Proxmox. No eran llamativos; simplemente eran disciplinados. Antes de cualquier cambio relacionado con hardware en una VM (CPU, firmware/modo BIOS, tipo de máquina), tomaban dos acciones: una instantánea de configuración del archivo de la VM y un procedimiento de rollback probado.

Un viernes, alguien cambió el tipo de CPU de una VM para “hacerla coincidir con los otros servidores” y poder migrar en vivo durante el parcheo. La VM no arrancó. El mensaje de error mencionaba una característica CPUID no soportada. El nivel de estrés subió; era semana de nómina, por supuesto.

El SRE de guardia no discutió con el universo. Restauró el /etc/pve/qemu-server/<vmid>.conf anterior desde su copia guardada, arrancó la VM y devolvió el negocio. Luego abrió un registro de cambio con dos seguimientos: elegir un modelo de CPU base soportado en los nodos y programar el cambio durante una ventana donde la reactivación y validación pudieran ocurrir.

Eso es lo de las prácticas aburridas: parecen lentas hasta el día que las necesitas. Entonces son lo más rápido que tienes.

Listas de verificación / plan paso a paso

Plan de recuperación paso a paso (mentalidad de mínima indisponibilidad)

Captura evidencia. Guarda la configuración actual de la VM y la salida del registro de tareas. Quieres algo de lo que aprender, no solo un servicio restaurado.
Lee el error de QEMU/KVM. No toques ajustes hasta saber si es “invalid model” vs “unsupported feature” vs “KVM init failure”.
Rollback del tipo de CPU al último conocido como bueno. Si la VM estuvo funcionando hoy, revierte. Arranca la VM. Restaura el servicio.
Si el rollback falla, quita personalizaciones. Borra banderas personalizadas y cualquier línea args: que afecte a -cpu. Mantén la configuración simple hasta que arranque.
Si sigue fallando, verifica la virtualización del host. Comprueba módulos KVM, banderas de CPU y ajustes BIOS. Reinicia host si hace falta.
Una vez arrancada, valida la salud del invitado. Acceso a consola, discos, red, servicios. Vigila licencias y problemas de controladores.
Sólo entonces reintenta un cambio de CPU. Elige un modelo base que exista en todos los nodos. Haz pruebas de arranque en cada nodo si la migración importa.

Lista de verificación: elegir un tipo de CPU que no te traicione luego

Si la VM nunca migra y quieres rendimiento: cpu: host está bien, pero documenta que está fijada a hardware compatible.
Si la VM puede migrar dentro de un clúster homogéneo: elige un modelo nombrado que exista y sea soportado en todos los nodos.
Si el clúster es mixto o esperas cambios futuros de hardware: elige una base conservadora (x86-64-v2 o similar) y acepta la pequeña pérdida de rendimiento.
Evita banderas de CPU ajustadas a mano a menos que puedas explicar cada una, probarla y revertirla.

Lista de verificación: procedimiento seguro de cambio (lo que haría en producción)

Registrar la configuración actual: copiar /etc/pve/qemu-server/<vmid>.conf.
Confirmar que QEMU soporta el modelo de CPU objetivo en cada nodo.
Confirmar que las CPUs físicas soportan las banderas necesarias en cada nodo.
Planear efectos secundarios en el invitado (activación de Windows, virtualización anidada, cambios de clocksource del kernel).
Cambiar solo el tipo de CPU primero. Arrancar y validar.
Sólo tras el éxito: plantear otros ajustes (NUMA, hugepages, pinning), uno por uno.

Preguntas frecuentes

1) ¿Por qué Proxmox me permite seleccionar un tipo de CPU que el host no puede ejecutar?

Porque Proxmox no es tu madre. Pasa tu petición a QEMU/KVM; KVM hace cumplir la realidad del hardware en tiempo de arranque. Algunas incompatibilidades solo son conocidas cuando QEMU ensambla la definición final de CPU.

2) ¿Es `cpu: host` siempre la mejor opción?

Mejor para rendimiento en nodo único, a menudo. Peor para migración en hardware mixto. Si necesitas movilidad, elige un modelo base y acepta que “banderas máximas en todas partes” no es lo mismo que “operaciones fiables”.

3) ¿Cuál es la diferencia entre modelos nombrados (Skylake, EPYC) y `x86-64-v2`/`v3`?

Los modelos nombrados mapean a microarquitecturas específicas con paquetes de banderas concretos. Los niveles x86-64-v* buscan una base ISA estandarizada mínima. Las bases suelen ser mejores para portabilidad; los modelos nombrados pueden ser mejores para rendimiento predecible dentro de una flota conocida.

4) La VM arranca tras cambiar el tipo de CPU, pero el rendimiento empeoró. ¿Debo revertir?

Si la carga usa instrucciones de cripto/compresión/vectoriales, probablemente quitaste una característica que necesitaba. Confírmalo comparando banderas de CPU dentro del invitado antes/después (o verificando la línea -cpu efectiva de QEMU). Si el rendimiento es crítico para el negocio, revierte y elige una base que preserve las características necesarias en todos los nodos.

5) ¿Puede un cambio de tipo de CPU corromper discos o datos?

No directamente. Los cambios de modelo de CPU afectan la exposición de instrucciones, no las escrituras de almacenamiento. El riesgo real es indirecto: crashes, sistemas de archivos invitados que no se apagan limpiamente o problemas a nivel de aplicación tras arranques inestables. Trátalo como cualquier cambio de identidad de hardware: valida el invitado y las aplicaciones.

6) ¿Por qué falló la migración en vivo de repente después de cambiar el tipo de CPU?

La migración en vivo necesita compatibilidad de CPU entre origen y destino. Si cambiaste a host en una CPU más nueva, la VM puede requerir características ausentes en otro nodo. Usa un tipo de CPU base del clúster para que la migración sea predecible.

7) ¿Necesito apagar la VM para cambiar el tipo de CPU?

Sí, en el sentido práctico. El modelo de CPU se establece al arrancar la VM. Puedes cambiar la configuración en caliente, pero no se aplicará hasta el siguiente arranque. Además: cambiar el tipo de CPU en una VM de producción en ejecución y “reiniciaremos más tarde” es cómo te dejas trampas para tu yo futuro.

8) ¿Cómo sé qué modelo de CPU ve realmente el invitado?

En el host, usa qm showcmd <vmid> para ver el argumento -cpu efectivo. Dentro de invitados Linux, lscpu y /proc/cpuinfo muestran lo que el invitado cree. En Windows, comprueba el nombre del CPU en el Administrador de tareas y usa herramientas de información del sistema.

9) ¿Cuál es el tipo de CPU “genérico” más seguro para un clúster Intel mixto?

A menudo x86-64-v2 es un punto de partida seguro si tus nodos son razonablemente modernos. Si tus nodos son más nuevos y has verificado soporte en todas partes, x86-64-v3 puede ser un buen compromiso. No adivines—valida en cada nodo.

10) Tenemos nodos Intel y AMD. ¿Podemos migrar la misma VM entre ambos?

En ocasiones sí, pero es complicado. Las diferencias de proveedor, los strings de CPUID expuestos y los conjuntos de características pueden romper suposiciones. Si debes hacerlo, usa bases conservadoras y prueba migraciones. En muchos entornos, la respuesta correcta es “no mezclar proveedores en un dominio de migración”.

Conclusión: próximos pasos para evitar recurrencias

Cuando una VM de Proxmox no arranca tras un cambio de tipo de CPU, la jugada ganadora casi siempre es: lee el error de QEMU, revierte a lo último que funcionó, arranca la VM y luego elige una base de CPU que encaje con tu realidad operativa.

Pasos prácticos siguientes:

Estandariza una política de tipo de CPU por clase de VM: VMs de rendimiento fijadas pueden usar host; VMs migrables deben usar una base soportada por todos los nodos.
Elimina sobrescrituras ocultas: quita líneas args: arriesgadas salvo que puedas justificarlas y probarlas.
Inventaría y alinea el clúster: modelos de CPU, microcode, ajustes BIOS de virtualización y versiones de Proxmox/QEMU no deben derivar sin control.
Haz las copias de configuración aburridas y rutinarias: guardar el archivo de configuración de la VM antes de cambios es el hábito aburrido que acorta las interrupciones.

Una idea de fiabilidad parafraseada de Werner Vogels: Todo falla, así que construye sistemas que esperen fallos y haz que la recuperación sea rápida. Aquí aplica. Los cambios de tipo de CPU son sobrevivibles—si los tratas como cambios reales de producción, no como una aventura en un menú desplegable.