¿Limita QEMU el rendimiento de las máquinas virtuales de Proxmox?
QEMU añade algo de sobrecarga a cada máquina virtual de Proxmox, pero rara vez es el motivo principal de que una carga de trabajo rinda mal. Proxmox combina QEMU con KVM, así que la mayoría de las instrucciones de procesador del invitado se ejecutan mediante las funciones de virtualización del procesador físico en lugar de traducirse por completo en software.
Los problemas de rendimiento suelen venir más de un hardware virtual inadecuado, un almacenamiento lento, una asignación excesiva de recursos, la presión de memoria o un diseño de red deficiente. Con los ajustes correctos, muchas máquinas virtuales de Proxmox pueden rendir cerca de sistemas físicos comparables.
¿Cómo afecta QEMU al rendimiento?
QEMU crea el equipo virtual que ve el sistema operativo invitado. Presenta procesadores virtuales, memoria, controladoras de disco, interfaces de red, firmware y otros dispositivos.
KVM aporta, por debajo de QEMU, la virtualización del procesador acelerada por hardware. Cuando la aceleración KVM está activa, las instrucciones de procesador del invitado pueden ejecutarse de forma eficiente con Intel VT x o AMD V, mientras QEMU sigue coordinando la máquina virtual y procesando la actividad de los dispositivos virtuales.
La sobrecarga viene de que el invitado tiene que comunicarse a través de hardware virtual antes de llegar al dispositivo físico de almacenamiento, red o gráficos, y su tamaño depende mucho del modelo de dispositivo virtual. Una tarjeta de red emulada intenta reproducir el comportamiento del hardware físico, así que cada interacción pasa por una lógica de emulación adicional. Un dispositivo VirtIO está diseñado para sistemas virtualizados y se comunica de forma más directa con el host. Proxmox describe la red VirtIO como la que ofrece el mejor rendimiento con una sobrecarga de procesador muy baja.
Así que QEMU está en la ruta que marca el rendimiento, y los administradores controlan en buena medida lo eficiente que es esa ruta.
¿Usa emulación por software una VM de Proxmox?
Una máquina virtual normal de Proxmox debería usar la aceleración por hardware de KVM. QEMU puede funcionar sin KVM mediante traducción por software, pero ese modo es mucho más lento y sirve sobre todo para emular una arquitectura de procesador distinta de la del host.
Si la virtualización por hardware está desactivada en el firmware del servidor, no está disponible para el sistema operativo o la oculta un hipervisor externo, la máquina virtual puede no ser capaz de usar KVM correctamente, y el rendimiento puede caer de forma drástica. Confirma que las extensiones de virtualización están activadas antes de probar ajustes más pequeños, porque cambiar la caché de disco no va a compensar la falta de aceleración por hardware.
¿Importa el tipo de CPU virtual?
El modelo de CPU seleccionado afecta tanto al rendimiento como a la compatibilidad.
Proxmox puede presentar al invitado un modelo de procesador estandarizado, lo que permite migrar máquinas virtuales entre nodos del clúster con generaciones distintas de procesadores físicos. La contrapartida es que algunas instrucciones más recientes del procesador pueden quedar ocultas para el invitado.
Poner el tipo de CPU virtual en host expone de forma más directa las capacidades del procesador físico del host. Proxmox indica que así el invitado recibe exactamente los mismos flags de CPU que el host. Puede mejorar el rendimiento de cargas de trabajo que se benefician de conjuntos de instrucciones más nuevos, extensiones de cifrado o funciones especializadas del procesador. El coste es la flexibilidad de migración, ya que una máquina virtual con el tipo de CPU host puede no migrar a un nodo con un procesador distinto o más antiguo.
Usa el tipo de CPU host en máquinas virtuales sensibles al rendimiento que se quedan en hardware compatible, y un modelo de CPU común para todo el clúster cuando una migración en caliente fiable importe más que exponer todas las instrucciones disponibles.
Más procesadores virtuales no hacen automáticamente más rápida una VM. Cada CPU virtual se convierte en un hilo planificable en el host Proxmox, y darle dieciséis procesadores virtuales a una aplicación con pocos hilos puede añadir trabajo de planificación sin mejorar su rendimiento. Empieza con el número que la aplicación puede aprovechar y auméntalo solo después de medir la saturación del procesador.
¿Limitan el rendimiento los ajustes del disco virtual?
La configuración del disco es una de las causas más comunes de un mal rendimiento de las máquinas virtuales.
Proxmox admite varias controladoras de almacenamiento emuladas y paravirtualizadas. Su documentación actual recomienda VirtIO SCSI single con IO Thread activado en los discos conectados cuando la prioridad es el rendimiento.
Un IO Thread saca el trabajo de almacenamiento compatible del bucle de eventos principal de QEMU. QEMU explica que añadir IO Threads puede repartir el trabajo entre bucles de eventos separados, lo que reduce la contención del bucle principal y puede mejorar la latencia de almacenamiento y el jitter del invitado. Esto importa sobre todo en servidores de bases de datos con mucha actividad, appliances de almacenamiento y máquinas virtuales que generan muchas peticiones de disco simultáneas; un servidor web con poco uso puede no mostrar apenas diferencia.
El almacenamiento subyacente sigue decidiendo mucho. VirtIO no puede hacer que una cabina lenta de discos duros se comporte como un almacenamiento rápido de estado sólido, y Proxmox depende de la latencia, la profundidad de cola, la protección de caché y el rendimiento de red del backend de almacenamiento elegido. Prueba todo el camino de almacenamiento, incluidos el sistema de archivos del invitado, la controladora virtual, la capa de almacenamiento de Proxmox y los discos físicos.
¿Importa el modo de caché del disco?
QEMU admite varios modos de caché de disco. El modo cambia cómo pasan los datos por la caché de páginas del host y cuándo se dan por completadas las escrituras.
La caché write back puede rendir bien, pero depende de un almacenamiento fiable y de protección eléctrica. Un fallo repentino puede poner en riesgo las escrituras confirmadas recientemente si todavía no han llegado al almacenamiento persistente.
Las configuraciones directas o sin caché pueden evitar la caché duplicada entre el invitado y el host, pero el rendimiento depende de la carga de trabajo y del sistema de almacenamiento. QEMU señala que los ajustes de caché y de entrada y salida asíncrona pueden tener un gran impacto en el rendimiento.
Ningún ajuste es a la vez el más rápido y seguro en todas partes, ya que una base de datos con escrituras síncronas necesita algo distinto de un servidor de compilación temporal. Haz pruebas de rendimiento con cargas de trabajo realistas y confirma que la configuración elegida mantiene las garantías de durabilidad que exige la aplicación.
¿Crea un cuello de botella la red virtual?
La red virtual añade sobrecarga de procesamiento, aunque los adaptadores de red VirtIO están diseñados para mantenerla baja.
Un adaptador emulado puede ayudar al instalar un sistema operativo antiguo que no tiene drivers VirtIO, pero normalmente no debería quedarse como opción a largo plazo en un invitado Linux o Windows moderno. Windows necesita los drivers VirtIO adecuados, mientras que la mayoría de las distribuciones Linux actuales incluyen soporte VirtIO en el kernel.
El rendimiento de red también depende de los bridges de Proxmox, las VLAN, las reglas del firewall, los adaptadores de red físicos y los switches a los que se conecta. Una máquina virtual no puede superar la capacidad del enlace físico ni la del origen de almacenamiento que le entrega los datos.
La red multicola puede mejorar el rendimiento de las máquinas virtuales con mucha actividad al permitir que el procesamiento de red use varias colas y núcleos de procesador. También puede aumentar el uso del procesador, así que ajusta el número de colas a la carga de trabajo en lugar de poner el valor más alto posible sin probar.
¿Reduce el rendimiento la virtualización de memoria?
La memoria de una máquina virtual tiene que traducirse entre las direcciones virtuales del invitado, las direcciones físicas del invitado y la memoria física del host. Los procesadores modernos aceleran estas traducciones, pero las cargas de trabajo intensivas en memoria pueden seguir notando sobrecarga.
Las huge pages pueden reducir los fallos del translation lookaside buffer al mapear regiones de memoria más grandes con menos entradas. La documentación del kernel Linux indica que las huge pages pueden aportar beneficios importantes en virtualización, incluso cuando solo las usa uno de los dos lados, el host o el invitado. Importan sobre todo en bases de datos grandes, sistemas de analítica y otras cargas de trabajo con conjuntos de trabajo de memoria considerables. También reservan o consumen memoria en unidades más grandes y pueden reducir la flexibilidad cuando el host está bajo presión de memoria.
El ballooning de memoria implica otra contrapartida. Permite a Proxmox ajustar el uso de memoria del invitado y obtener mejor información de uso, lo que puede mejorar el aprovechamiento del host, pero las cargas de trabajo sensibles al rendimiento suelen ir mejor con una disponibilidad de memoria predecible.
Evita la sobreasignación agresiva de memoria en bases de datos y servicios sensibles a la latencia. En cuanto el host empieza a hacer swap, la actividad de almacenamiento puede borrar cualquier ganancia del ajuste de CPU o de VirtIO.
¿Puede el passthrough de dispositivos eliminar la sobrecarga de QEMU?
El passthrough PCI asigna un dispositivo físico directamente a una máquina virtual, lo que puede dar un acceso casi nativo a tarjetas gráficas, adaptadores de red, controladoras de almacenamiento y otro hardware.
El passthrough reduce el procesamiento de dispositivos virtuales del que se encarga QEMU, pero trae restricciones operativas. La máquina virtual pasa a depender del hardware instalado en un nodo concreto, y la migración en caliente y la recuperación automática en alta disponibilidad se complican. También requiere un aislamiento IOMMU adecuado y hardware compatible.
Úsalo cuando la carga de trabajo necesite de verdad acceso directo al dispositivo. La mayoría de las cargas de servidor corrientes no lo necesitan, y VirtIO les da mejor portabilidad y rendimiento suficiente.
¿Cómo deberías medir el rendimiento de QEMU?
Compara el rendimiento con pruebas a nivel de aplicación en lugar de fiarte solo de benchmarks sintéticos. Prueba una base de datos con su patrón de transacciones esperado, un servidor de archivos con tamaños de archivo y usuarios concurrentes realistas, y una aplicación web con peticiones representativas.
Monitorea tanto el invitado como el host Proxmox durante la prueba. Una máquina virtual con una latencia de disco alta puede estar esperando al almacenamiento físico, y un invitado que muestra capacidad de procesador sin usar puede seguir sufriendo retrasos porque el host está sobrecargado.
Cambia un ajuste cada vez. Si sustituyes a la vez el tipo de CPU, la controladora de disco, el modo de caché y el adaptador de red, es difícil saber qué ajuste ayudó o cuál causó un problema nuevo.
¿Limita QEMU el rendimiento de Proxmox?
QEMU introduce una sobrecarga de virtualización inevitable, pero normalmente no impide que las máquinas virtuales de Proxmox rindan bien. Los malos resultados suelen deberse más a dispositivos emulados, modelos de CPU incorrectos, almacenamiento lento, IO Threads sin activar, sobreasignación de memoria o demasiados procesadores virtuales.
Usa la aceleración por hardware de KVM, adaptadores de red VirtIO, VirtIO SCSI single con IO Threads cuando corresponda y un almacenamiento diseñado para la carga de trabajo. Plantéate el modelo de CPU host, las huge pages y el passthrough de dispositivos solo cuando su beneficio de rendimiento justifique la pérdida de portabilidad o flexibilidad.
En un entorno de Proxmox bien configurado, es poco probable que QEMU sea el principal cuello de botella; es el diseño general de la infraestructura lo que decide si la máquina virtual rinde bien.