KVM, Xen o LXC: que ejecuta realmente tu VPS

Lo que realmente vende su plan VPS

KVM, Xen y LXC son las tres familias de virtualización sobre las que se construye un plan VPS. La elección no es un detalle del rack del proveedor. Determina si dispone de su propio kernel. Todo lo que le importa a un comprador depende de ese hecho: cargar módulos, controlar la swap, ejecutar virtualización anidada, saber si /proc describe su servidor o el de otra persona y determinar si el steal time se puede medir.

La virtualización completa (KVM y Xen HVM) proporciona a cada cliente un kernel y una máquina virtual. Xen paravirtualizado también proporciona un kernel, pero este sabe que es un guest y solicita al hipervisor que realice las operaciones privilegiadas. Un plan basado en contenedores (LXC o la línea OpenVZ y Virtuozzo) proporciona un sistema de archivos y un conjunto de namespaces sobre el kernel del proveedor. Las tres opciones se comercializan con las mismas tres letras.

KVM frente a Xen y LXC: un kernel por instancia o un kernel compartido

En KVM y Xen, uname -r identifica el kernel de su instancia. Puede instalar otro, cargar un módulo y reiniciar con él. Nada de lo que haga allí afecta a otro inquilino. En un plan de contenedores, uname -r identifica el kernel del proveedor, que se ejecuta en el host y se comparte con todos los demás contenedores de esa máquina. No puede cambiarlo, y apt install linux-image-generic descomprimirá archivos que nunca llegarán a arrancar.

Esta única diferencia es más importante que cualquier tabla de especificaciones. Lea el resto de esta guía como una serie de consecuencias de esa diferencia.

Virtualización completa: KVM y Xen HVM

KVM (kernel-based virtual machine) es un módulo del kernel de Linux que convierte un host Linux normal en un hipervisor mediante las instrucciones Intel VT-x o AMD-V integradas en la CPU. QEMU proporciona el hardware virtual que lo rodea: disco, tarjeta de red y consola serie. Xen utiliza un diseño diferente. Xen es su propio hipervisor y se inicia antes que Linux. Un dominio de control con privilegios, llamado dom0, ejecuta la pila de administración, y cada cliente es un domU. Xen HVM (hardware virtual machine) utiliza las mismas extensiones de CPU que KVM, normalmente con controladores paravirtualizados para disco y red porque el hardware emulado es lento. Esta combinación se denomina PVHVM.

Para un cliente, ambos funcionan casi igual. Obtiene un kernel, un gestor de arranque, un dispositivo de bloques real, un modprobe operativo, un /proc real, su propia swap y un reinicio que realmente vuelve a arrancar. Si el proveedor permite conectar una ISO, puede instalar una distribución que nunca ofreció.

Esto reduce la densidad. Sus 4 GB están asignados a su máquina y no pueden prestarse a otro cliente mientras permanecen inactivos, y cada invitado incluye un proceso de QEMU, sus propias tablas de páginas y su propia caché de páginas. Este coste explica que un plan KVM tenga un precio superior al de un plan de contenedores con las mismas cifras.

Xen paravirtualizado y cómo reconocerlo

Xen PV apareció antes de que las CPU incorporaran instrucciones de virtualización. En lugar de interceptar las instrucciones privilegiadas, el kernel invitado se modifica para llamar directamente al hipervisor. Funciona sin VT-x, que era precisamente el objetivo en 2005. pygrub o pvgrub carga el kernel desde la propia imagen de disco, por lo que es su kernel, pero debe estar compilado con compatibilidad con invitados PV.

Estas son algunas señales de que está usando uno: lscpu indica para como tipo de virtualización, en lugar de full; existe /sys/hypervisor/type y muestra Xen; y los discos son xvda, no vda ni sda. Las herramientas que leen las tablas SMBIOS o DMI no encuentran nada, porque un invitado PV no tiene firmware que las publique.

La virtualización anidada queda descartada de forma permanente. Un invitado PV nunca recibe las extensiones de virtualización de la CPU, por lo que ningún hipervisor puede ejecutarse dentro de él. Xen no ha desaparecido. Lo que ha perdido presencia es Xen PV en particular, y la dirección del propio proyecto se ha desplazado hacia PVH y HVM. Si un plan indica "Xen", pregunte cuál de los dos. HVM es un VPS moderno normal. PV es un plan cuyo precio debería ser menor.

Contenedores VPS: LXC y la línea OpenVZ

Un VPS en contenedor es un conjunto de espacios de nombres de Linux (vistas separadas de los identificadores de procesos, los montajes, las interfaces de red, el nombre de host y los usuarios) junto con cgroups (grupos de control, los límites de recursos del kernel) que se ejecutan en el kernel del proveedor. Su init es un proceso del host. Su ls se ejecuta directamente en el kernel del host, sin emulación ni un segundo planificador de por medio. Por eso los contenedores son rápidos y permiten una alta densidad.

Los nombres que aparecen en una página de contratación son LXC, contenedores de Proxmox VE (que utilizan LXC), OpenVZ y Virtuozzo. OpenVZ 7 y Virtuozzo son los descendientes comerciales de la misma idea.

Cuatro aspectos cambian para usted:

• Módulos. modprobe no insertará nada. Si WireGuard, ZFS o un módulo específico de netfilter no está ya disponible en el kernel del proveedor, no podrá utilizarlo.
• sysctl. La mayor parte de /proc/sys es de sólo lectura. La red utiliza un espacio de nombres real, por lo que net.ipv4.ip_forward y sus elementos vecinos normalmente se pueden modificar. Los parámetros de alcance global del equipo, como vm.swappiness o fs.file-max, pertenecen al host.
• Contenedores anidados. Docker dentro de un contenedor LXC sólo funciona cuando el proveedor habilita el anidamiento y el controlador de almacenamiento es compatible. Pruébelo antes de contratarlo en lugar de darlo por hecho.
• La versión del kernel. Depende del calendario de actualizaciones del proveedor, incluidos los reinicios.

Cómo saber cuál compraste

Ejecuta estos comandos en el equipo y analiza las respuestas en conjunto. Ningún comando por sí solo permite determinarlo.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt muestra un identificador corto de un vocabulario fijo. El lado de la máquina incluye kvm, qemu, xen, amazon y vmware. El lado del contenedor incluye lxc, lxc-libvirt, openvz, docker y systemd-nspawn. Cuando no detecta nada, muestra none y termina con un código distinto de cero. La forma -c sólo responde para tecnologías de contenedores, por lo que cualquier respuesta distinta de none permite resolver la cuestión, independientemente de lo que indicara la página de venta.

lscpu indica el proveedor del hipervisor y si el tipo de virtualización es completa o para, que es la forma de distinguir Xen HVM de Xen PV. /sys/hypervisor/type sólo existe en Xen.

La comprobación /lib/modules es la que muchas personas omiten y es la más directa. Si falta el directorio correspondiente a la versión del kernel en ejecución, o está vacío, mientras el sistema está ejecutando claramente ese kernel, el kernel no procede de tu sistema de archivos. Lo proporciona el host, y su árbol de módulos nunca se instaló en tu imagen. Eso indica que es un contenedor.

Como segunda opinión independiente, sudo apt install -y virt-what && sudo virt-what ejecuta las pruebas de detección como una herramienta específica. Necesita root y no muestra ninguna salida en bare metal.

Por qué /proc describe la máquina equivocada en un contenedor

En un invitado KVM o Xen, /proc/meminfo es el registro que hace el kernel propio de la memoria que le ha asignado el hipervisor. Describe correctamente su máquina y no dice nada del host. Ese es el propósito de una máquina virtual.

En un contenedor no hay un segundo kernel que haga ese registro, por lo que /proc es el /proc del host. LXCFS es un sistema de archivos pequeño que reescribe algunos de esos archivos para adaptarlos a los límites del cgroup, y cubre /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats y /sys/devices/system/cpu/online. Proxmox lo monta de forma predeterminada. Muchos proveedores pequeños no lo hacen. En ese caso, free -m informa de la memoria total del host, nproc puede informar de todos los núcleos de la máquina y uptime indica cuánto tiempo lleva funcionando el host.

Esto no es un detalle cosmético, porque el software ajusta su tamaño a partir de esos archivos. nginx con worker_processes auto cuenta los núcleos que puede ver. make -j$(nproc) en un host con 64 núcleos y una cuota de 2 núcleos inicia 64 compiladores. Una JVM o una base de datos que elige el tamaño de la caché a partir de MemTotal selecciona un valor que el cgroup rechazará, y el kernel mata el proceso cuando alcanza el límite. Ese proceso terminado queda registrado en el registro del kernel del host, que usted no puede leer.

Los valores autoritativos están en el cgroup, no en /proc:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Esas son rutas de cgroup v2, que es lo que usan las distribuciones actuales. Leer memory.max en max significa que no hay ningún límite establecido en ese nivel. cpu.max muestra una cuota y un periodo en microsegundos, por lo que 200000 100000 equivale a 2 núcleos de tiempo de CPU por periodo. En un host antiguo con cgroup v1, los mismos valores se encuentran en /sys/fs/cgroup/memory/memory.limit_in_bytes y /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Intercambio y quién lo administra

En KVM y Xen, el área de intercambio es suya. Es un archivo o una partición del disco, y el kernel se encarga de la paginación.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show debería mostrar ahora el archivo con su tamaño y prioridad. Si swapon rechaza el archivo, créelo con dd if=/dev/zero of=/swapfile bs=1M count=2048 en su lugar, porque algunos sistemas de archivos rechazan un archivo preasignado con extensiones sin escribir. Añada /swapfile none swap sw 0 0 a /etc/fstab; de lo contrario, el área de intercambio desaparecerá tras el siguiente reinicio.

En un contenedor, nada de eso está bajo su control. swapon necesita una capacidad que un contenedor sin privilegios no tiene, por lo que crear su propio archivo de intercambio falla por falta de permisos y nunca llega al disco. Lo que el plan denomina intercambio es un ajuste de cgroup en el host, memory.swap.max con cgroup v2, respaldado por los propios dispositivos de intercambio del host. Los planes antiguos de OpenVZ vendían una cuota de «vswap» que se parecía más a un crédito para picos de consumo que a espacio en disco. Puede consultar el límite. No controla el dispositivo que hay detrás.

Virtualización anidada y el indicador de CPU que engaña

La virtualización anidada consiste en ejecutar un hipervisor dentro de su VPS: un invitado QEMU, una box de Vagrant o un laboratorio de virtualización anidada con sus propias máquinas virtuales. Deben cumplirse dos condiciones. El proveedor debe habilitar la virtualización anidada en el host y el invitado debe recibir las extensiones de virtualización de la CPU.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

En un invitado KVM con la virtualización anidada habilitada, /dev/kvm existe y kvm-ok indica claramente si se puede usar la aceleración. En Xen HVM es técnicamente posible, pero rara vez se ofrece. En Xen PV no puede funcionar.

En un contenedor, la comprobación falla de una forma ilustrativa. /proc/cpuinfo es el archivo del host, por lo que el indicador vmx o svm está presente y es realmente correcto: la CPU física que está debajo sí tiene esas instrucciones. Aun así, no son suyas. No existe ningún /dev/kvm en su espacio de nombres, no puede cargar el módulo kvm_intel y el indicador que acaba de leer describe la máquina en la que está alojado, no una máquina que usted controle. Este es el ejemplo más claro de la regla general. En un contenedor, /proc describe el espacio de nombres y el hardware que lo rodea, no un servidor que le pertenezca.

AES-NI y las funciones de CPU que expone tu plan

AES-NI (advanced encryption standard new instructions) es un conjunto de instrucciones de CPU que hace que el cifrado AES sea varias veces más rápido que realizar las mismas operaciones mediante software. La terminación TLS, el cifrado de discos, SSH y las canalizaciones de copias de seguridad dependen de estas instrucciones.

En KVM, lo que ve el sistema invitado depende del modelo de CPU que el proveedor haya configurado para QEMU. Con host passthrough se muestran las flags reales. Con un modelo genérico como qemu64, o con una línea base deliberadamente antigua para permitir la migración de invitados entre hosts incompatibles, la flag aes puede no estar disponible y OpenSSL vuelve silenciosamente a la ruta de software.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

El tercer comando es el ejemplo del manual de OpenSSL para desactivar esas instrucciones dentro de la biblioteca: borra el bit de AES-NI y el bit de VAES, y deja intacto el resto. Compara las dos cifras de rendimiento. Si son similares, la ruta rápida no se estaba utilizando desde el principio. En ese caso, comprobar correctamente AES-NI en un VPS merece los cinco minutos necesarios antes de contratar un plan.

Un contenedor no tiene un modelo de CPU propio, por lo que las flags de /proc/cpuinfo son las flags reales del host y se aplican a tu entorno. Esta es una ventaja real de los planes basados en contenedores y el único punto de esta guía en el que el kernel compartido juega a tu favor.

De dónde procede el steal time y por qué un contenedor no lo tiene

El steal time es el tiempo durante el que la CPU virtual estaba lista para ejecutarse, pero no lo hizo porque el hypervisor estaba ejecutando otra carga. Aparece como st en top y vmstat, y como el octavo campo de la línea cpu en /proc/stat.

Un guest no puede medirlo por sí mismo porque no se está ejecutando mientras le quitan ese tiempo. El hypervisor debe comunicárselo. KVM escribe un total acumulado en una página que el guest registra mediante su interfaz de reloj paravirtualizado, y Xen mantiene un área de estado de ejecución por vCPU para la misma finalidad. El valor que se lee es la propia declaración del hypervisor. Por eso existe y por eso se puede considerar fiable.

Un steal time alto indica que el host está sobreasignado y que las cargas vecinas están ocupadas en ese momento. Es la manifestación visible de la relación entre las vCPU vendidas y los núcleos físicos. Leer el steal time para detectar una carga vecina ruidosa es la única medición que indica si un plan tiene realmente el tamaño que anuncia.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

En un contenedor, esa columna no cambiará porque no hay ningún hypervisor entre usted y el scheduler. Sus procesos esperan junto a los procesos de los demás tenants como tareas normales en el scheduler de CPU del propio host. La contención se manifiesta simplemente como un mayor tiempo de ejecución, sin ningún contador que indique la causa. El equivalente más cercano es el throttling por cuota: cuando el proveedor establece cpu.max, /sys/fs/cgroup/cpu.stat cuenta los periodos nr_throttled y los microsegundos throttled_usec pasados a la espera de la siguiente ventana de cuota. Esto sólo cubre su propia cuota, nunca la competencia de los tenants vecinos. Hay una salvedad: si el host de contenedores del proveedor es a su vez una máquina virtual, puede aparecer un valor de steal en /proc/stat, pero pertenece a ese host y no a usted.

La sobreventa y por qué el plan de contenedor es más barato

La respuesta es breve. Un plan de contenedor cuesta menos porque el proveedor comparte la misma máquina entre más usuarios.

La memoria es donde la diferencia es mayor. La RAM de un huésped KVM está asignada a ese huésped, por lo que un host con 256 GB vende aproximadamente 256 GB de huéspedes, menos la sobrecarga. El límite de memoria de un contenedor es un techo, no una reserva. La memoria que un contenedor no utiliza queda disponible de inmediato para los demás. Por eso, el proveedor puede vender límites que suman varias veces la RAM física y acertar casi siempre. No se falsifica nada. Funciona hasta que suficientes inquilinos están ocupados al mismo tiempo. Entonces deja de funcionar para todos.

La CPU está sobrevendida en todos los tipos de plan, incluido KVM, porque se venden más vCPU que núcleos disponibles. El almacenamiento se aprovisiona de forma ligera prácticamente en todas partes. Los contenedores aumentan aún más la densidad: usan un solo kernel y una sola caché de páginas, y no necesitan un proceso QEMU por huésped. Por eso, un host puede alojar varias veces más inquilinos.

Lo que se pierde es aislamiento, y ese es un compromiso de ingeniería real, no una táctica para alarmar. Se comparte el kernel, por lo que un error del kernel es un problema compartido. Además, una fuga del contenedor llega directamente al host. Escapar de una máquina virtual requiere un error del hypervisor, que ofrece un objetivo mucho menor y más difícil de explotar. También se hereda el calendario del proveedor para actualizar el kernel y reiniciar. Si algo de esto es importante para usted, lea qué tan seguro es realmente el alojamiento VPS antes de elegir basándose sólo en el precio.

Qué comprar

Compre KVM cuando necesite su propio kernel: módulos de WireGuard o ZFS, una versión específica del kernel, virtualización anidada, control real sobre el swap o una frontera que pueda explicar a un auditor. Compre un plan de contenedores cuando ejecute servicios habituales con un presupuesto limitado, el kernel del proveedor esté actualizado y haya confirmado que las funciones de las que depende ya están compiladas en él. Considere Xen HVM equivalente a KVM para la mayoría de los usos y haga esta pregunta antes de comprar algo que todavía se venda como Xen PV.

Hay dos opciones que quedan fuera de esta división. Las microVM de Firecracker proporcionan a cada tenant un kernel real con unos costes de arranque similares a los de un contenedor. Eso es lo que utilizan las plataformas serverless. Los contenedores de sistema de Incus permiten ejecutar usted mismo el modelo de contenedores en hardware que controla. Es una situación distinta de que le vendan uno. Si la terminología es el problema, qué es realmente un VPS y la diferencia entre un VPS, una VM y una VPC explican los términos que esta guía da por conocidos.

FAQ

¿Cómo sé si mi VPS usa KVM o es un contenedor?

Ejecute systemd-detect-virt -c. Cualquier respuesta distinta de none indica que está dentro de un contenedor, independientemente del nombre del producto que figure en el plan. Confírmelo de otras dos formas, porque la detección puede inducir a error. lscpu muestra el proveedor del hipervisor e indica si el tipo de virtualización es completa o para. ls /lib/modules/$(uname -r) falta o está vacío en un contenedor, porque el kernel en ejecución procede del host y su árbol de módulos nunca se instaló en su sistema de archivos. sudo virt-what proporciona una respuesta independiente mediante una herramienta escrita específicamente para esta comprobación.

¿Por qué free -m muestra mucha más memoria de la que incluye mi plan?

Está usando un plan de contenedor sin LXCFS montado, por lo que /proc/meminfo es el archivo del host y free informa correctamente de la memoria del host. Su límite real lo establece el cgroup. Lea /sys/fs/cgroup/memory.max para consultar el límite y /sys/fs/cgroup/memory.current para consultar el uso actual, o /sys/fs/cgroup/memory/memory.limit_in_bytes en un host antiguo con cgroup v1. Configure cualquier servicio que ajuste una caché o un grupo de workers a partir de ese valor y no de free.

¿Puedo ejecutar Docker o WireGuard en un VPS LXC?

A veces, y nunca depende de algo que usted instale. Ambos dependen del kernel del proveedor, porque no puede cargar módulos en él. WireGuard funciona cuando el módulo ya está presente en el host y el proveedor lo expone, y la implementación de espacio de usuario wireguard-go es la alternativa cuando no está disponible. Docker necesita que el proveedor permita el anidamiento y un controlador de almacenamiento que funcione dentro de un contenedor. Pregunte antes de comprar o haga la prueba durante un periodo que pueda cancelar sin consecuencias.

¿Por qué mi VPS contenedor nunca informa de tiempo robado?

El tiempo robado sólo existe cuando un hipervisor planifica una CPU virtual, y se informa porque ese hipervisor escribe el valor en una página que lee el kernel. Un contenedor no tiene un hipervisor debajo. Sus procesos son tareas normales del planificador del host, por lo que la contención se manifiesta en que todo tarda más, sin ningún contador que lo indique. Lea /sys/fs/cgroup/cpu.stat en su lugar: nr_throttled y throttled_usec contabilizan el tiempo que su cgroup pasó esperando su siguiente ventana de cuota de CPU, que es lo más parecido al tiempo robado que tiene un contenedor.