Tus VMs se sienten “lentas”, así que empiezas a comprar CPUs como si fuera una experiencia religiosa. Mientras tanto, el verdadero culpable suele ser un grupo IOMMU faltante, un interruptor en la BIOS, un gobernador de CPU mal configurado o un host que está fijando interrupciones en el mismo núcleo al que fijaste tu VM “sensible a latencia”. Bienvenido a la virtualización doméstica: el lugar donde el eslabón más débil siempre es el que no pensaste revisar.
Esta es la visión práctica y orientada a producción sobre las características de la CPU que realmente importan para ejecutar KVM/Proxmox, ESXi, Hyper-V, bhyve o Xen en casa. No listas de marketing. No supersticiones de foros. Características, modos de fallo y cómo probar lo que tienes con comandos.
Qué importa realmente (y qué no)
Si estás montando o actualizando una máquina de virtualización doméstica, la elección de CPU es sobre todo capacidad primero, consistencia segundo y velocidad bruta al final. La mayoría de laboratorios caseros no fallan por carecer de un 5% más de rendimiento single-thread. Fallan porque una función “soportada” no está realmente disponible o se comporta mal bajo carga.
Características de CPU que son condición mínima
- Virtualización por hardware: Intel VT-x o AMD-V. Sin esto, los hipervisores modernos o bien no arrancan o funcionan como en 2006.
- Traducción de direcciones de segundo nivel: Intel EPT o AMD NPT (Nested Paging). Es la diferencia entre “las VMs se sienten nativas” y “las VMs son un castigo”.
- IOMMU: Intel VT-d o AMD-Vi. Necesario para passthrough serio de PCI (GPUs, HBAs, NICs) y útil para aislamiento incluso sin passthrough.
- Firmware decente: BIOS/UEFI que exponga las funciones de forma fiable y no venga con valores por defecto extraños.
Características de CPU que importan según la carga
- AES-NI / VAES: Si ejecutas almacenamiento cifrado (ZFS native encryption, LUKS), VPNs o servicios con mucho TLS, esto puede ser crítico.
- AVX2/AVX-512: Útil para cargas concretas (transcodificación de medios, algunas bases de datos/analítica). También puede reducir boost turbo o aumentar consumo. Hay compensaciones.
- TSX, RDT, etc.: Herramientas de afinado empresarial. Ocasionalmente útiles, a menudo irrelevantes en casa.
Características de CPU por las que la gente se obsesiona demasiado
- “Más núcleos siempre gana”: Hasta que saturas el ancho de banda de memoria, la caché L3 o la capacidad del host para programar interrupciones.
- “Solo pasar la GPU”: Genial cuando funciona. Una pesadilla de soporte cuando los grupos IOMMU están pegados por el diseño de la placa base.
- “ECC o nada”: ECC es buena ingeniería, pero no es lo único que te separa del caos. (Además no es una característica de CPU; es una característica de plataforma.)
Una verdad dura: la virtualización es menos sobre “ejecutar muchos SO” y más sobre “hacer que la memoria y el I/O se comporten educadamente bajo contención”. Las características de CPU que mejoran la virtualización de memoria y el aislamiento de dispositivos son las que realmente marcan la diferencia.
Datos interesantes y contexto histórico
Porque el contexto evita errores caros, aquí tienes puntos concretos que explican por qué existen estas funciones y por qué le importan a tu hipervisor:
- La traducción binaria fue algo real. Antes de que VT-x/AMD-V maduraran, los hipervisores usaban trucos para reescribir instrucciones privilegiadas. Funcionaba, pero era complejo y más lento en algunas cargas.
- EPT/NPT cambió el juego más que VT-x/AMD-V. La “virtualización hardware” temprana sin buena traducción de segundo nivel seguía sufriendo por shadow page tables.
- IOMMU no se inventó para gamers. Venía de necesidades empresariales: aislamiento DMA, asignación de dispositivos más segura y evitar que un dispositivo escriba sobre la memoria de otro.
- Las salidas de VM son el recaudador de impuestos. Cada vez que una VM tiene que rebotar al hipervisor por algo privilegiado, pagas. Las CPUs modernas añaden funciones específicamente para reducir exits.
- La virtualización anidada solía ser terrible. Ejecutar un hipervisor dentro de una VM (para CI, laboratorios o “porque puedo”) era doloroso hasta que las CPUs mejoraron y los hipervisores aprendieron a cooperar.
- Meltdown/Spectre cambiaron las suposiciones de rendimiento base. Las mitigaciones aumentaron la sobrecarga en algunas operaciones de kernel/hipervisor; ciertas generaciones de CPU se vieron más afectadas.
- SR-IOV es un primo del passthrough. En lugar de dar una NIC completa a una VM, la divides en virtual functions. Genial cuando está soportado; irrelevante cuando tu NIC no lo hace.
- Intel y AMD usan nombres distintos para ideas similares. VT-x vs AMD-V, EPT vs NPT, VT-d vs AMD-Vi. El objetivo es el mismo: reducir el trabajo del hipervisor.
Extensiones de virtualización hardware: lo imprescindible
Desmitifiquemos la base.
VT-x / AMD-V: necesario, no suficiente
Las extensiones de virtualización hardware permiten a la CPU ejecutar código invitado en un modo especial y trapear operaciones sensibles al hipervisor de forma segura. La mayoría de CPUs modernas lo tienen. La trampa es asumir que “tiene VT-x” significa “CPU buena para virtualización”. Es como asumir que “tiene volante” significa “coche de carreras”.
Lo que te importa:
- Estabilidad bajo carga: la calidad del firmware y la madurez del microcódigo importan.
- Completitud de funciones: EPT/NPT, virtualización de interrupciones, posted interrupts, etc.
- Soporte en tu hipervisor: que una función exista en silicio no garantiza que tu plataforma la use bien.
Broma #1: Comprar una CPU para virtualización porque tiene “VT-x” es como comprar un coche porque tiene “un volante”. Técnicamente correcto. Prácticamente inútil.
Virtualización anidada: si la quieres, planifícala
La virtualización anidada es común en empresas reales para pipelines de CI, entornos de laboratorio y pruebas de automatización de hipervisores. En casa es de nicho, pero si ejecutas Kubernetes-en-VMs que a su vez ejecutan otras VMs (te estoy mirando), quieres soporte de CPU+hipervisor para virtualización anidada y probarlo pronto.
IOMMU/VT-d/AMD-Vi: passthrough y aislamiento
Si quieres passthrough de GPU, HBA o “mi VM router tiene su propia NIC”, estás en territorio IOMMU. Aquí es donde las construcciones domésticas triunfan o fracasan por rarezas de la plataforma más que por el modelo de CPU.
Qué hace realmente la IOMMU
La IOMMU es al DMA lo que un MMU es al acceso de la CPU a memoria. Permite al sistema controlar qué direcciones de memoria puede leer/escribir un dispositivo vía DMA. Sin ella, pasar un dispositivo a una VM es peligroso porque el dispositivo podría hacer DMA sobre la memoria del host. Con ella, puedes mapear direcciones visibles por el dispositivo a la memoria del invitado de forma segura.
El problema de los grupos IOMMU
El passthrough no es “¿puedo activar VT-d?”. Es “¿están los dispositivos que necesito aislados en grupos IOMMU manejables?”. Las placas base a veces cablean múltiples dispositivos detrás del mismo root complex PCIe sin separación ACS adecuada. Resultado: tu GPU está en el mismo grupo que un controlador SATA que necesita el host. Disfruta tus opciones.
Entrega de interrupciones y latencia
Incluso con IOMMU, el rendimiento depende de cómo se manejan las interrupciones. Los sistemas modernos pueden hacer remapeo de interrupciones, y los hipervisores pueden usar funciones como posted interrupts para reducir VM exits. Es crucial para redes de alto número de paquetes y almacenamiento de baja latencia.
Postura operativa: si el passthrough es un requisito central, compra una plataforma conocida por comportarse bien. La marca de CPU importa menos que el comportamiento de la placa base y el chipset.
EPT/NPT, TLBs y por qué la virtualización de memoria es la verdadera clave
Cuando alguien dice “sobrecarga de virtualización”, normalmente se refiere a “algo sobre la CPU”. La verdad: el mayor dolor histórico fue la traducción de memoria y la churn que causa en caches y TLBs.
Traducción de direcciones de segundo nivel (SLAT)
Intel EPT y AMD NPT permiten que la CPU traduzca las direcciones virtuales del invitado a direcciones físicas del invitado y luego a direcciones físicas del host, con ayuda hardware. Sin ello, el hipervisor mantiene shadow page tables, y cada actualización de la tabla de páginas del invitado se convierte en trabajo caro. SLAT elimina una enorme cantidad de sobrecarga.
TLBs, tamaños de página y por qué a veces ayudan las hugepages
Los Translation Lookaside Buffers (TLBs) cachean traducciones de direcciones. La virtualización añade otra capa, por lo que la presión sobre el TLB puede empeorar. Las hugepages (2MB, 1GB según) pueden reducir misses de TLB para VMs con mucha memoria, pero también pueden aumentar la fragmentación o complicar el overcommit de memoria. Es una herramienta, no una religión.
Overcommit: el precipicio de rendimiento
A los laboratorios caseros les encanta el overcommit porque la RAM es cara y el optimismo es gratis. Las características de CPU no te salvarán si el host empieza a usar swap. Una vez que ves swap-in/swap-out bajo carga de VM, tu problema de “rendimiento de CPU” es realmente un problema de capacidad y comportamiento de memoria.
Núcleos vs frecuencias vs caché: elegir la forma de la CPU
La elección de CPU no es solo “qué tan rápido”. Es “cómo se comporta cuando 12 cosas quieren servicio a la vez”. Los hipervisores amplifican los malos trade-offs porque multiplexan todo.
Núcleos: concurrencia y margen de scheduling
Más núcleos significan más hilos ejecutables que pueden progresar sin esperar. Esto es genial para muchos servicios pequeños, cargas CI y “ejecuto todo en VMs separadas porque se siente más ordenado”. Pero más núcleos también pueden significar:
- Menor turbo en todos los núcleos bajo carga sostenida
- Menos caché por núcleo (dependiendo del SKU)
- Comportamiento NUMA más complejo en multi-socket (menos común en casa)
Frecuencias: latencia y rendimiento en cola
El rendimiento single-thread sigue importando para:
- El camino de paquetes de PFSense/OPNsense en algunas configuraciones
- Servidores de juego
- Algunos caminos de almacenamiento (checksum, compresión, cifrado) según la configuración
- Cualquier carga con una sección crítica serializada
En cargas mixtas, la latencia en cola es la que mata. Una CPU que hace boost alto en unos pocos núcleos mientras mantiene otros ocupados puede sentirse mejor que un chip “más núcleos, menor boost”, incluso si el benchmark dice lo contrario.
Caché: la característica invisible de rendimiento
La caché L3 es la MVP silenciosa para densidad de virtualización. Muchas VMs significan muchos working sets. Los fallos de caché implican tráfico de memoria; tráfico de memoria implica contención; la contención hace que todo sea irregular y “aleatorio”.
Regla empírica: si ejecutas muchos servicios con uso moderado de CPU (típico laboratorio doméstico), favorece CPUs con L3 decente y comportamiento estable en todos los núcleos por encima del pico de boost de marketing.
AES, AVX e instrucciones que cambian el juego
AES-NI (y similares): si cifras algo, te importa
AES-NI acelera operaciones criptográficas comunes. Si ejecutas:
- ZFS native encryption
- LUKS/dm-crypt
- Túneles VPN (WireGuard depende más de operaciones de curva; IPsec/OpenVPN puede apoyarse en AES)
- Mucha terminación TLS (reverse proxies, PKI interna, service meshes)
…entonces AES-NI puede convertir “cripto limitado por CPU” en “I/O-límite normal”. También reduce jitter: la criptografía sin aceleración puede robar CPU en el peor momento posible.
AVX2/AVX-512: rendimiento con advertencias
AVX puede acelerar masivamente ciertas cargas de cómputo. También puede:
- Aumentar el consumo energético
- Disparar frecuencias de CPU más bajas en algunas CPUs bajo cargas AVX sostenidas
- Provocar misterios del tipo “¿por qué el host es más lento cuando esa VM corre?”
En un entorno doméstico donde una VM puede monopolizar el host, tareas intensivas en AVX pueden ser un vecino ruidoso. No hay que temer a AVX. Hay que entenderlo y aislarlo si hace falta (pinning de CPU, cuotas, host separado).
CRC32, multiplicación sin acarreo y el mito de “CPU de almacenamiento”
Las pilas de almacenamiento usan varias instrucciones CPU para checksums y compresión. ZFS, por ejemplo, se beneficia de una CPU potente para checksumming y compresión, pero la mayoría de construcciones domésticas están limitadas por discos o NICs antes que por CPU. La excepción es cuando activas compresión costosa, cifrado intenso o trabajas a 10/25GbE con SSDs rápidos. Entonces la CPU se convierte en el motor de almacenamiento.
Topología, SMT, NUMA y los silenciosos crímenes del scheduler
La CPU no es una piscina plana de núcleos idénticos. Los sistemas modernos tienen SMT (Hyper-Threading), caches compartidas, chiplets y a veces núcleos heterogéneos. Hipervisores y schedulers del host hacen lo mejor. También te engañan con educación.
SMT: mayor rendimiento, a veces peor latencia
SMT puede aumentar el rendimiento en cargas mixtas. Pero si fijas vCPUs uno a uno con pCPUs y olvidas que SMT existe, puedes acabar fijando dos vCPUs ruidosas en los mismos hilos hermanos del núcleo físico. Así es como obtienes “la VM tiene núcleos dedicados pero sigue tartamudeando”.
NUMA: mayormente un problema de servidor, hasta que no lo es
En plataformas de un solo socket para consumidor, los efectos NUMA existen pero son menos dramáticos. En sistemas multi-socket o estaciones de trabajo de alto conteo de núcleos, un mal emplazamiento NUMA puede doblar la latencia de memoria para una VM. Si compras un servidor dual-socket usado porque era barato y ruidoso (y lo será), aprende lo básico de NUMA o acepta que algunas VMs tendrán rendimiento misterioso.
Gestión de energía: el saboteador silencioso
El escalado de frecuencia es genial para portátiles. En un host de VM, “powersave” puede parecer picos de latencia aleatorios. Los modos balanced pueden estar bien, pero debes comprobar qué está haciendo realmente el host. Si tu host hipervisor debe ser un pequeño servidor, trátalo como tal.
Broma #2: El gobernador “powersave” en un host de VM es como poner tu base de datos en un retiro de yoga. Encontrará su paz interior justo cuando necesites respuestas.
Mitigaciones de seguridad: impuesto de rendimiento con recibos
Spectre, Meltdown, L1TF, MDS, SSB, Retbleed—elige tu acrónimo. Las mitigaciones a menudo afectan la sobrecarga de llamadas al sistema, cambios de contexto y rutas de virtualización.
El consejo operativo:
- No desactives mitigaciones a la ligera. Los laboratorios caseros también son objetivo. Tu VM router y tu VM NAS no son copos de nieve especiales.
- Conoce la generación de tu CPU. Algunas generaciones sufren más con ciertas mitigaciones.
- Mide antes/después. Las mitigaciones no son universalmente “lentas”. Algunas cargas apenas las notan.
Una idea parafraseada de una leyenda de operaciones: “La esperanza no es una estrategia.” —idea atribuida a Gene Kranz (disciplina de operaciones de misión). En términos de virtualización: no esperes que una función exista; verifícala en tu hardware y firmware exactos.
Tareas prácticas: comandos, salidas, decisiones (12+)
Estos son los chequeos que realmente ejecuto cuando diagnostico un host, valido una compra o confirmo un cambio de BIOS. Cada tarea tiene: un comando, qué significa la salida típica y la decisión que tomas.
Tarea 1: Confirmar flags de virtualización de la CPU (VT-x/AMD-V)
cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|CPU\(s\)'
CPU(s): 16
Model name: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
Virtualization: VT-x
Significado: “Virtualization: VT-x” indica que el kernel ve soporte de virtualización por hardware.
Decisión: Si esto falta (o está en blanco), comprueba la BIOS/UEFI para Intel VT-x/AMD SVM. Si sigue faltando, tu CPU/plataforma puede no soportarlo o estar bloqueado.
Tarea 2: Confirmar EPT/NPT (traducción de segundo nivel)
cr0x@server:~$ grep -Eo 'vmx|svm|ept|npt' /proc/cpuinfo | sort | uniq -c
16 ept
16 vmx
Significado: La presencia de ept (Intel) o npt (AMD) indica soporte SLAT, crítico para rendimiento.
Decisión: Si tienes VT-x/AMD-V pero no EPT/NPT, trata esa CPU como una mala opción de virtualización para cargas modernas.
Tarea 3: Verificar que los módulos KVM están cargados y son utilizables
cr0x@server:~$ lsmod | egrep 'kvm|kvm_intel|kvm_amd'
kvm_intel 372736 0
kvm 1032192 1 kvm_intel
irqbypass 16384 1 kvm
Significado: KVM está activo; irqbypass suele aparecer en contextos de virtualización.
Decisión: Si los módulos KVM no cargan, comprueba las opciones de virtualización en la BIOS y dmesg para mensajes “disabled by bios”.
Tarea 4: Comprobar si IOMMU está habilitado en el kernel
cr0x@server:~$ dmesg | egrep -i 'iommu|dmari|amd-vi' | head -n 8
[ 0.842311] DMAR: IOMMU enabled
[ 0.842451] DMAR: Intel(R) Virtualization Technology for Directed I/O
[ 0.924113] DMAR: Interrupt remapping enabled
Significado: IOMMU está activada; el remapeo de interrupciones es una buena señal para passthrough más seguro.
Decisión: Si no ves “IOMMU enabled”, probablemente necesitas VT-d/AMD-Vi en BIOS más parámetros de kernel (por ejemplo, intel_iommu=on o amd_iommu=on).
Tarea 5: Confirmar que cmdline del kernel incluye opciones IOMMU
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0 root=UUID=... ro quiet intel_iommu=on iommu=pt
Significado: intel_iommu=on habilita IOMMU; iommu=pt a menudo mejora el rendimiento del host usando mapping de passthrough para dispositivos del host.
Decisión: Si necesitas passthrough, añade las banderas correctas y reconstruye la configuración del bootloader. Si no necesitas passthrough, puedes habilitar IOMMU para aislamiento, pero mide regresiones.
Tarea 6: Inspeccionar grupos IOMMU (viabilidad de passthrough)
cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:"; lspci -nns $(ls "$g/devices" | sed 's/^/0000:/'); echo; done | head -n 30
IOMMU Group 0:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e30]
IOMMU Group 1:
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]
IOMMU Group 2:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1f82]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa]
Significado: Los dispositivos en el mismo grupo no se pueden separar de forma segura sin ACS. Que una GPU esté agrupada con su función de audio es normal y manejable.
Decisión: Si tu dispositivo objetivo comparte grupo con algo que el host necesita (controlador USB, controlador SATA), planifica una ranura distinta, otra placa o acepta no hacer passthrough.
Tarea 7: Validar que el hipervisor puede exponer características de CPU a invitados
cr0x@server:~$ virsh capabilities | egrep -n 'model|feature' | head -n 12
32: Skylake-Client
41: Significado: libvirt ve modelos de CPU y características que puede presentar a las VMs.
Decisión: Para VMs sensibles al rendimiento, prefiere el modo CPU “host-passthrough” (cuando no te importen las migraciones). Para clusters mixtos, usa un modelo de CPU baseline estable.
Tarea 8: Comprobar el gobernador de frecuencia actual (los picos de latencia suelen vivir aquí)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Significado: El host está priorizando ahorro de energía, lo que puede introducir latencia y lentitud.
Decisión: Considera cambiar a performance en un host dedicado de VMs, especialmente si ves jitter. Mide consumo y térmicas.
Tarea 9: Cambiar el gobernador a performance (temporal) y verificar
cr0x@server:~$ sudo apt-get install -y linux-cpupower
Reading package lists... Done
...
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
...
cr0x@server:~$ cpupower frequency-info | egrep -i 'governor|current policy' | head -n 6
current policy: frequency should be within 800 MHz and 4.70 GHz.
The governor "performance" may decide which speed to use
Significado: El gobernador cambió; se muestra el rango de la política.
Decisión: Si la latencia de las VMs mejora, haz el cambio persistente mediante las herramientas de gestión de energía de tu distro.
Tarea 10: Comprobar swap en el host (a menudo diagnosticado mal como “CPU débil”)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 31Gi 26Gi 1.2Gi 3.1Gi 3.8Gi 1.6Gi
Swap: 16Gi 6.5Gi 9.5Gi
Significado: Uso activo de swap bajo carga es una bandera roja para rendimiento de VMs y la capacidad de respuesta del host.
Decisión: Reduce el overcommit de memoria, añade RAM, ajusta la política de ballooning de VMs o mueve servicios hambrientos de memoria fuera de este host. Las actualizaciones de CPU no arreglarán el swap.
Tarea 11: Identificar steal time de CPU dentro de una VM (contención del host)
cr0x@server:~$ mpstat 1 5
Linux 6.5.0 (vm01) 01/12/2026 _x86_64_ (4 CPU)
12:01:02 PM all %usr %nice %sys %iowait %irq %soft %steal %idle
12:01:03 PM all 12.00 0.00 4.00 0.00 0.00 1.00 18.00 65.00
Significado: %steal indica que la VM quiso tiempo de CPU pero el host no la programó. Eso es contención, no “Linux está lento”.
Decisión: Reduce overcommit, fija vCPUs, reserva CPU para VMs críticas o añade núcleos. También revisa si hay una VM vecina ruidosa.
Tarea 12: Detectar puntos calientes de interrupciones (cuellos de botella NIC/almacenamiento disfrazados de CPU)
cr0x@server:~$ cat /proc/interrupts | head -n 12
CPU0 CPU1 CPU2 CPU3
24: 987654 0 0 0 IR-PCI-MSI 327680-edge nvme0q0
25: 0 876543 0 0 IR-PCI-MSI 327681-edge nvme0q1
34: 4321098 0 0 0 IR-PCI-MSI 524288-edge enp3s0-rx-0
Significado: Un CPU recibiendo la mayoría de interrupciones de un dispositivo de alto tráfico puede crear latencia y reducir el rendimiento de la VM.
Decisión: Asegura que irqbalance esté en ejecución (o fija afinidad de interrupciones intencionalmente), distribuye colas entre CPUs y evita fijar VMs críticas al núcleo saturado por interrupciones.
Tarea 13: Verificar que el microcódigo está aplicado (estabilidad y mitigaciones)
cr0x@server:~$ dmesg | egrep -i 'microcode' | tail -n 5
[ 0.321987] microcode: microcode updated early to revision 0x000000f0, date = 2023-09-12
Significado: Las actualizaciones de microcódigo pueden corregir erratas, mejorar estabilidad y afectar el comportamiento de mitigaciones.
Decisión: Mantén los paquetes de microcódigo actualizados. Si ves fallos de virtualización extraños, confirma que no estás usando microcódigo antiguo.
Tarea 14: Comprobar el estado de mitigaciones (expectativas de rendimiento)
cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -n 10
/sys/devices/system/cpu/vulnerabilities/meltdown: Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS: disabled; STIBP: conditional; RSB filling
Significado: El kernel te dice qué mitigaciones están activas. Algunas impactan más el rendimiento de VMs que otras.
Decisión: Si aparece una regresión en benchmarks tras actualizaciones, revisa esta salida. No adivines. Decide si aceptas el impuesto o rediseñas (p. ej., menos VM exits, mejor I/O, otra generación de CPU).
Tarea 15: Medir el modelo y flags de CPU por VM (ejemplo QEMU/KVM)
cr0x@server:~$ sudo virsh dumpxml vm01 | egrep -n 'cpu mode|model|feature' | head -n 20
57:
Significado: host-passthrough expone las características de la CPU del host al invitado, normalmente maximizando el rendimiento.
Decisión: Si necesitas migración en caliente entre CPUs distintas, no uses host-passthrough; usa un modelo de CPU compatible. Si no migras, host-passthrough suele ser la mejor opción.
Guion rápido de diagnóstico
Cuando “las VMs están lentas”, no empieces por leer páginas de marketing de CPU. Empieza por encontrar el cuello de botella con un triage despiadado.
Primero: determina si es scheduling de CPU, presión de memoria o I/O
- Carga del host y run queue: ¿está el CPU del host saturado o simplemente “ocupado”?
- Actividad de swap: si hay swapping, para. Arregla la memoria primero.
- I/O wait: si iowait es alto, las características de CPU no son tu factor limitante.
Segundo: comprueba contadores específicos de virtualización
- Steal time de VM: dentro del invitado, busca
%steal. - VM exits (indirecto): verifica si una carga está causando syscalls excesivas, interrupciones o emulación (p. ej., virtio mal configurado).
- Distribución de interrupciones: IRQs calientes en un núcleo pueden parecer lentitud “aleatoria”.
Tercero: valida firmware y conmutadores de funciones
- VT-x/AMD-V activado
- VT-d/AMD-Vi activado
- SR-IOV activado (si es necesario)
- BIOS y microcódigo actualizados
- Modo de gestión de energía apropiado para un host
Cuarto: decide si necesitas una CPU nueva o un plan nuevo
- Si hay swap, compra RAM o reduce overcommit.
- Si domina iowait, arregla almacenamiento/red (colas, drivers, elección de dispositivo).
- Si hay mucho steal time, añade núcleos, reduce consolidación o aísla VMs ruidosas.
- Si passthrough falla, probablemente necesites otra placa base más que otra CPU.
Tres microhistorias corporativas desde el frente
Incidente por una suposición errónea: “VT-d está activado, así que passthrough funcionará”.
Un pequeño equipo de infraestructura decidió estandarizar en una estación de trabajo compacta para una oficina remota. El objetivo era simple: unas pocas VMs más passthrough de GPU para una carga Windows que necesitaba aceleración gráfica real. Comprobaron la CPU: virtualización soportada, VT-d soportado. ¿Hecho, verdad?
Construyeron la primera unidad, instalaron el hipervisor, activaron VT-d en la BIOS y ejecutaron las comprobaciones habituales de IOMMU. IOMMU estaba habilitado. Todos respiraron tranquilos. Luego intentaron asignar la GPU a la VM y se toparon con un muro: la GPU estaba en el mismo grupo IOMMU que un controlador USB y un bridge PCIe que también albergaba un dispositivo onboard crítico. Asignar todo el grupo habría significado quitar hardware al host. No es un truco divertido cuando el host necesita ese controlador para arrancar con fiabilidad.
La primera reacción del equipo fue “arreglar Linux”. Intentaron parches de ACS override. Funcionó parcialmente hasta que no lo hizo: reinicios aleatorios bajo carga y fallos DMA ocasionales que parecían problemas de driver. No era un problema de driver. Era la topología PCIe de la plataforma y límites de aislamiento débiles.
Acabaron cambiando la placa base por una con mejor cableado de ranuras PCIe y comportamiento ACS apropiado. Misma CPU. Misma GPU. De repente todo se comportó. La lección no fue “passthrough es difícil”. La lección fue: el soporte de funciones de CPU es necesario, pero el cuerpo está enterrado en la placa base.
Optimización que salió mal: “Pineemos todo para rendimiento”.
Otro equipo operaba un cluster de virtualización con mezcla de servicios web, logging y un par de VMs sensibles a latencia. Un ingeniero decidió ponerse serio: pinning de CPU, isolcpus, perfiles tuned, todo. En papel se veía precioso—núcleos dedicados para VMs importantes, menos context switches, más determinismo.
En la práctica, el rendimiento empeoró. Las VMs sensibles a latencia se detenían ocasionalmente y la carga softirq del host se disparó. El ingeniero había fijado vCPUs cuidadosamente, pero olvidó que las interrupciones y los hilos del kernel aún necesitan CPU. Peor aún, una cola NIC de alto tráfico y una cola NVMe terminaron dirigiéndose al mismo núcleo “aislado” debido a la afinidad IRQ por defecto.
El resultado fue clásico: la VM tenía “CPU dedicada”, pero la CPU dedicada estaba ocupada manejando interrupciones y tareas de mantenimiento del host. El pinning redujo la capacidad del scheduler de suavizar picos, así que los picos se hicieron más agudos. Los usuarios lo notaron. Grafana se volvió una antología de horror.
Lo arreglaron relajando el pinning agresivo, configurando explícitamente afinidades IRQ y reservando un par de núcleos para el host. El efecto neto no fue tan “limpio” como el diagrama, pero fue estable. Afinar rendimiento es una negociación con la realidad; la realidad no lee tu runbook.
Práctica aburrida pero correcta que salvó el día: modelos de CPU base y control de cambios
Una empresa mediana ejecutaba un entorno de virtualización donde la migración en caliente era importante. Tenían una mezcla de generaciones de CPU porque la renovación de hardware ocurre por oleadas, no en un evento sagrado. Aprendieron pronto que el modo “host-passthrough” es fantástico hasta que necesitas migrar una VM a un host con un conjunto de características de CPU ligeramente distinto.
Así que hicieron algo aburrido: estandarizaron modelos de CPU de VM a una línea base conservadora y documentaron las flags de CPU requeridas. También mantuvieron una checklist pre-actualización: ajustes de BIOS, versiones de microcódigo y una “VM canaria” que ejecutaba un pequeño conjunto de pruebas después de los cambios.
Un fin de semana, un host falló y un lote de VMs necesitó migrar. El cluster lo hizo sin drama. La línea base de características evitó fallos de migración, y la VM canaria ya había validado la nueva imagen del host a principios de semana. No hubo depuración heroica a las 2 a. m., solo operaciones normales.
No fue glamuroso. Fue correcto. Y en ingeniería de fiabilidad, “aburrido” es un cumplido.
Errores comunes: síntomas → causa raíz → solución
1) El passthrough de GPU no arranca; QEMU se queja de IOMMU
Síntomas: La VM no arranca con passthrough; los logs mencionan DMAR/IOMMU, “VFIO: No IOMMU” o problemas de reset de dispositivo.
Causa raíz: VT-d/AMD-Vi deshabilitado en BIOS, parámetros del kernel faltantes o grupos IOMMU no aislados.
Solución: Habilita VT-d/AMD-Vi en BIOS; añade intel_iommu=on o amd_iommu=on; comprueba grupos IOMMU; si los grupos son malos, cambia placa/ranura o reconsidera el passthrough.
2) Las VMs tartamudean bajo carga aunque el uso de CPU “parece bajo”
Síntomas: Lag interactivo, glitches de audio, pérdida de paquetes, pero la CPU promedio parece estar bien.
Causa raíz: Escalado de frecuencia de CPU (powersave), tormentas de interrupciones en un solo núcleo o steal time por oversubscription.
Solución: Pon el gobernador en performance; distribuye IRQs; reserva núcleos para el host; reduce oversubscription; mide %steal dentro de las VMs.
3) El rendimiento de almacenamiento se desploma al habilitar cifrado/compresión
Síntomas: Alta CPU en hilos del kernel, aumento de latencia de I/O, throughput muy por debajo de la capacidad de disco/NIC.
Causa raíz: Aceleración AES ausente o mal expuesta a invitados, o la CPU se convierte en el cuello de botella por ajustes costosos.
Solución: Verifica flags AES-NI/VAES en host y guest; usa modo CPU host-passthrough cuando corresponda; ajusta compresión; considera CPU más rápida o estrategia de offload.
4) La migración en caliente falla con “CPU incompatible”
Síntomas: La migración se niega; error menciona características de CPU faltantes.
Causa raíz: Uso de host-passthrough o exposición de funciones no presentes en el host destino.
Solución: Estandariza en un modelo de CPU base; enmascara flags; mantén hosts del cluster dentro de una familia de CPU compatible si la migración es obligatoria.
5) Caídas aleatorias de VMs después de “tuning de rendimiento”
Síntomas: Reinicios ocasionales, lockups, deriva de tiempo o errores de dispositivo tras pinning/ajustes.
Causa raíz: Aislamiento de CPU demasiado agresivo, IRQs mal fijadas, hilos del kernel del host hambrientos o undervolt/overclock inestable.
Solución: Revierta ajustes exóticos; asigna núcleos para housekeeping del host; asegúrate de que el microcódigo esté actualizado; desactiva overclocks en una máquina con rol de servidor.
6) Throughput de red pobre a pesar de CPU potente
Síntomas: Bajo throughput, alta softirq, drops de paquetes, un núcleo CPU al 100%.
Causa raíz: Virtio mal configurado, colas insuficientes, problemas de afinidad IRQ o falta de offloads/SR-IOV cuando se necesita.
Solución: Usa virtio-net con multiqueue; confirma distribución de IRQs; considera SR-IOV o passthrough de NIC si necesitas línea casi completa con baja CPU.
Listas de verificación / plan paso a paso
Paso a paso: elegir CPU/plataforma para un hipervisor doméstico
- Define los “imprescindibles”. ¿Passthrough de GPU? ¿Passthrough de HBA? ¿Enrutamiento 10GbE? ¿Cifrado en todas partes? Si sí, prioriza comportamiento IOMMU y aceleración AES.
- Elige la plataforma, no solo la CPU. El layout PCIe de la placa, la madurez de la BIOS y el soporte del chipset decidirán tu día a día.
- Verifica SLAT. Asegura EPT (Intel) o NPT (AMD). Trátalo como obligatorio para virtualización moderna.
- Decide postura de migración. Host único: host-passthrough está bien. Múltiples hosts con migración: estandariza modelo/funciones de CPU.
- Dimensiona la RAM antes que los núcleos. Si solo puedes permitir una actualización, la RAM previene los peores fallos de rendimiento.
- Reserva núcleos para el host. Deja margen para interrupciones, ZFS y el propio hipervisor.
- Planifica térmicas y energía. Una CPU que hace throttling es una CPU que te engaña.
Paso a paso: validar un host nuevo antes de mover cargas
- Actualiza BIOS/UEFI a una versión estable.
- Instala actualizaciones de microcódigo y confírmalo en dmesg.
- Activa VT-x/AMD-V y VT-d/AMD-Vi en BIOS.
- Arranca con flags IOMMU en el kernel si necesitas passthrough.
- Verifica grupos IOMMU y confirma que tus dispositivos objetivo son aislables.
- Configura el gobernador de CPU a una política conocida; mide jitter.
- Ejecuta una VM canaria: prueba de red, disco, CPU y un ciclo de reinicio.
- Sólo entonces migra servicios reales.
Paso a paso: estabilizar rendimiento en un host existente
- Comprueba uso de swap y arregla la presión de memoria primero.
- Comprueba %steal dentro de VMs clave para detectar oversubscription.
- Comprueba iowait para ver si el almacenamiento es el cuello de botella.
- Inspecciona interrupciones por puntos calientes; arregla distribución de IRQ.
- Verifica drivers virtio y ajustes de multiqueue.
- Considera pinning sólo si también puedes gestionar interrupciones y reservar núcleos para el host.
FAQ
1) ¿Necesito VT-x/AMD-V para virtualización doméstica?
Sí, para hipervisores modernos y rendimiento razonable. Sin ello, estás bloqueado o forzado a modos lentos/limitados. Trátalo como obligatorio.
2) ¿De verdad EPT/NPT es tan importante?
Sí. SLAT (EPT/NPT) es uno de los mayores habilitadores de rendimiento para VMs. Si evalúas CPUs antiguas, esta es la característica que debe decidir “no”.
3) Activé VT-d/AMD-Vi. ¿Por qué sigue fallando el passthrough?
Porque los grupos IOMMU y la topología PCIe de la placa deciden qué se puede aislar. También revisa parámetros del kernel, remapeo de interrupciones y que el dispositivo soporte reset requerido por VFIO.
4) ¿Debo elegir más núcleos o más frecuencia?
Para laboratorios domésticos típicos (muchos servicios, carga moderada), más núcleos con buena caché y boost estable en todos los núcleos gana. Para unas pocas VMs sensibles a latencia, mayores frecuencias sostenidas pueden sentirse mejor. Si quieres ambos, el presupuesto sube.
5) ¿SMT/Hyper-Threading ayuda en virtualización?
A menudo sí para throughput, a veces no para predictibilidad de latencia. Si haces pinning de CPU, sé consciente de SMT para no fijar dos vCPUs pesadas en hilos hermanos del mismo núcleo.
6) ¿Necesito AVX-512?
Sólo si ejecutas cargas que realmente lo usan. Para muchas cargas domésticas AVX-512 es irrelevante. Además puede afectar el comportamiento de frecuencia. Cómpralo por una razón, no por ostentación.
7) ¿AES-NI importa si no uso VPN?
Sigue siendo útil. El cifrado aparece en cifrado de disco, backups, TLS y a veces en pipelines de checksumming/compresión de almacenamiento. Si cifras datos en reposo, la aceleración AES merece atención.
8) ¿Debo desactivar mitigaciones de seguridad para recuperar rendimiento?
Generalmente no. Si haces benchmarks y entiendes el riesgo, puedes probar. Para servicios reales—incluso en casa—mantén mitigaciones activas y arregla rendimiento reduciendo contención, mejorando I/O o actualizando hardware.
9) ¿IOMMU sirve aunque no haga passthrough?
Sí, para aislamiento DMA y postura de seguridad, pero puede añadir complejidad. Si no lo necesitas, puedes dejarlo apagado. Si podrías necesitarlo luego, actívalo temprano y valida estabilidad.
10) ¿Una “CPU de servidor” puede ser peor que una de consumidor para virtualización doméstica?
Sí. CPUs de servidor antiguas pueden tener muchos núcleos pero peor single-thread, mayor consumo y peor impacto por mitigaciones. Pueden ser excelentes para throughput masivo; pueden sentirse lentas para cargas mixtas e interactivas.
Siguientes pasos que puedes hacer
Si quieres el camino más corto a una mejor experiencia de virtualización doméstica:
- Ejecuta los comandos de verificación arriba en tu host actual: SLAT, IOMMU, gobernador, swap, interrupciones, %steal.
- Arregla los problemas baratos primero: configura un gobernador sensato, detén el swap, corrige virtio y la distribución de IRQ.
- Si necesitas passthrough, valida grupos IOMMU antes de comprar cualquier otra cosa. Una CPU nueva no arreglará una placa que no aísla dispositivos.
- Si compras hardware, prioriza: EPT/NPT + IOMMU fiable + suficientes núcleos + caché adecuada + capacidad de RAM en la plataforma.
- Mide después de cada cambio. Los laboratorios domésticos son donde nacen mitos de rendimiento; la medición previene que los alimentes.