Cómo funciona KVM por dentro
KVM convierte el kernel de Linux en un hipervisor de tipo 1 exponiendo un dispositivo de carácter /dev/kvm. Un proceso en espacio de usuario (normalmente QEMU) abre ese dispositivo, pide al kernel crear una CPU virtual y luego ejecuta las instrucciones del huésped directamente en la CPU física utilizando las extensiones de virtualización por hardware. El kernel gestiona los eventos privilegiados; el resto se ejecuta a velocidad nativa.
Tres componentes hacen funcionar a KVM. Primero, el módulo del kernel kvm.ko gestiona la virtualización de CPU y memoria y expone la interfaz /dev/kvm. Segundo, un módulo específico de arquitectura —kvm-intel.ko para Intel VT-x o kvm-amd.ko para AMD-V— traduce entre la API genérica de KVM y las instrucciones de virtualización de la CPU subyacente. Tercero, un proceso de hipervisor en espacio de usuario, como QEMU, cloud-hypervisor o Firecracker, proporciona la emulación de dispositivos: discos virtuales, NICs, controladoras USB y firmware BIOS o UEFI. Como el kernel de Linux es el propio hipervisor, todo planificador, gestor de memoria y función de seguridad de Linux se aplica a las VMs igual que a los procesos nativos. Un huésped KVM no es más que un proceso pesado desde el punto de vista del kernel, motivo por el cual herramientas como top, perf y cgroups funcionan sobre él sin modificaciones.
KVM frente a OpenVZ frente a VMware ESXi frente a Hyper-V
KVM ofrece virtualización completa por hardware con un kernel huésped independiente para cada VM. OpenVZ utiliza contenerización a nivel de SO, donde cada contenedor comparte el kernel anfitrión. VMware ESXi es un hipervisor de tipo 1 propietario sobre metal, con su propio kernel (VMkernel). Hyper-V es el hipervisor de tipo 1 de Microsoft basado en Windows. Solo KVM, ESXi y Hyper-V proporcionan un kernel huésped real y aislado.
OpenVZ (y su sucesor Virtuozzo) es una tecnología de contenedores, no un hipervisor. Cada contenedor OpenVZ comparte el kernel Linux del anfitrión, lo que significa que no se puede ejecutar una versión de kernel diferente, no se pueden cargar módulos personalizados ni un sistema operativo distinto de Linux. La contrapartida es la densidad: como no hay sobrecarga de kernel por VM, un host OpenVZ puede compactar más contenedores en el mismo hardware, motivo por el cual los planes de VPS compartido más económicos lo usaban con frecuencia. VMware ESXi es el estándar empresarial para virtualización de tipo 1, pero se distribuye como producto de código cerrado con licencias por socket que históricamente lo dejaban fuera del hosting VPS de bajo coste. Hyper-V domina los entornos Windows Server y se integra estrechamente con Active Directory y System Center, pero es una elección menos habitual en flotas de hosting principalmente Linux. KVM se ha convertido en el valor predeterminado del hosting VPS moderno porque es de código abierto, está integrado en el kernel principal, soporta cualquier SO huésped que se ejecute en x86_64 o aarch64 y cuenta con un ecosistema de gestión maduro (libvirt, oVirt, Proxmox, OpenStack Nova).
Por qué KVM es el valor predeterminado moderno para VPS
KVM se convirtió en la tecnología de VPS dominante porque ofrece a cada cliente un kernel real y aislado sin pagar licencias estilo VMware. Soporta huéspedes Linux, Windows, BSD y Solaris, se ejecuta en hardware x86_64 y ARM básico y está integrado en todas las grandes pilas de orquestación: OpenStack, Proxmox VE, Kubernetes vía KubeVirt y AWS Nitro se construyen sobre él.
Tres fuerzas convergieron para hacer de KVM el estándar. Primera, las extensiones de virtualización por hardware se generalizaron: Intel VT-x se incluyó en los chips Core 2 en 2006 y AMD-V en los primeros Athlon 64, por lo que a principios de la década de 2010 prácticamente cualquier CPU de servidor podía alojar KVM a velocidad casi nativa. Segunda, la comunidad Linux rechazó adoptar la paravirtualización al estilo Xen en el kernel principal pero integró KVM en 2007, dando de inmediato un hipervisor incorporado a todas las distribuciones. Tercera, el ecosistema de cloud público invirtió fuerte: Google Cloud Engine se lanzó sobre KVM, AWS migró de Xen a una arquitectura Nitro basada en KVM y OpenStack estandarizó KVM como hipervisor de referencia. Los proveedores de VPS más pequeños se benefician de este efecto de gravedad porque el mismo tooling que mueve flotas de hyperscalers —libvirt, drivers virtio, cloud-init— funciona también en un único rack de servidores básicos.
Características reales de rendimiento: CPU steal, IO y sobrecarga
En un host KVM correctamente aprovisionado, espere una sobrecarga de CPU de un solo dígito frente a metal puro, latencia de red sub-milisegundo añadida en rutas de red local, y entre el 80 % y el 95 % de las IOPS de disco nativas cuando se usa virtio-blk o virtio-scsi con un driver paravirtualizado. Un CPU steal time sostenido por encima del 5 % es la señal canónica de host saturado y un indicador claro para actualizar.
Tres números importan para un huésped KVM en producción. El CPU steal time, expuesto en /proc/stat como octavo campo, mide el porcentaje de tiempo que la CPU virtual estaba lista para ejecutarse pero la CPU física estaba ocupada con otros huéspedes. Cualquier valor por debajo del 1-2 % es ruido de fondo normal; valores sostenidos por encima del 5 % indican que el host está sobrecomprometido y su carga está siendo limitada. El IO wait, expuesto por iostat y top, mide el porcentaje de tiempo que la CPU pasó bloqueada en disco o red. Con drivers paravirtualizados virtio y almacenamiento NVMe moderno, un IO wait sostenido superior al 20 % en una carga que debería ser ligada a CPU es una señal clara de que el subsistema de disco está saturado. El throughput de red en virtio-net debería alcanzar el 80-95 % de la velocidad nominal de la NIC física; cualquier valor sustancialmente inferior apunta a un offload mal configurado o a un viejo driver e1000 emulado.
Cuándo NO usar KVM
KVM es la elección incorrecta en tres situaciones: cargas en contenedores de altísima densidad donde la sobrecarga de kernel por VM domina, despliegues sensibles a la licencia de Windows donde el precio SPLA de Hyper-V es sustancialmente más barato, y ciertos escenarios de baja latencia con passthrough de hardware donde SR-IOV o el passthrough de GPU están mal soportados con su modelo concreto de NIC o GPU.
Para microservicios en contenedores que no necesiten aislamiento de kernel, los contenedores Linux (Docker, Podman, Kubernetes) ejecutándose directamente sobre metal puro empacan entre 3 y 5 veces más que cualquier VPS basado en KVM, porque cada contenedor es solo un grupo de procesos con namespaces y cgroups. Los proveedores de VPS de bajo coste sensibles a la densidad históricamente eligieron OpenVZ por la misma razón. Los despliegues con mucho Windows —especialmente los que ejecutan licencias de Windows Server adquiridas mediante SPLA— a veces pagan sustancialmente menos en Hyper-V que en KVM por cómo Microsoft tarifica las licencias de huésped en hipervisores competidores. Por último, ciertos escenarios de passthrough de hardware siguen siendo dolorosos en KVM: el passthrough de GPU exige que los grupos IOMMU estén limpiamente aislados, algunas NICs de consumo no admiten SR-IOV y el passthrough PCIe de unidades NVMe a veces dispara workarounds del bug de reset. Para el 95 % de las cargas Linux VPS de propósito general, nada de esto aplica y KVM es el valor predeterminado correcto.
Cómo verificar que un VPS realmente usa KVM
Dentro de un huésped Linux, ejecute `systemd-detect-virt`: debería imprimir `kvm`. Contraste con `lscpu` (la línea "Hypervisor vendor" debería leer "KVM") y `dmesg | grep -i kvm`. Si en su lugar ve "OpenVZ", "lxc" o "VMware", su proveedor utiliza otra tecnología, aunque el marketing diga otra cosa.
Antes de firmar un contrato, ejecute una pequeña batería de diagnóstico en un VPS de prueba. Ejecute `systemd-detect-virt` para la salida canónica de detección. Ejecute `cat /proc/cpuinfo | grep -E 'vmx|svm'` para confirmar que las extensiones de virtualización por hardware se traspasan (algunos proveedores las eliminan, rompiendo la virtualización anidada). Ejecute `uname -r` para verificar que ve un kernel específico de huésped y no un kernel anfitrión compartido: en un VPS KVM real puede instalar otro kernel mediante `apt install linux-image-...` o `dnf install kernel-...` y reiniciar en él. En OpenVZ no podrá. Por último, compruebe `/proc/user_beancounters`: si ese archivo existe, el host está ejecutando OpenVZ, sin importar lo que diga el marketing.