KVM vs OpenVZ vs LXC — por qué importa el tipo de virtualización

Tu propio kernel, RAM reservada, swap real, imágenes de Windows o BSD — la virtualización completa cambia lo que un VPS ejecuta. Core a $6/mes de lista, $4.80 anual-efectivo.

El benchmark que hiciste en la tienda miente sobre la producción

Todo gráfico comparativo favorece a los contenedores por un pequeño porcentaje, y todos esos gráficos se tomaron sobre un host inactivo sin nada más en marcha. Las puntuaciones sintéticas miden la frontera del hipervisor que puedes sentir; no miden al vecino ruidoso que conocerás en el tercer mes, cuando el trabajo de copias de seguridad de otra persona reescribe el pool de memoria sobre el que está parada tu base de datos. Compra por el segundo número, no por el primero.

KVM le presenta a cada servidor hardware virtual y arranca sobre él un kernel real de tu elección. El coste es una fina capa de traducción — unos pocos por ciento en microbenchmarks frente a los actuales hosts EPYC y Ryzen con memoria ECC, como lo plantean las propias páginas del proyecto KVM. La recompensa es un muro sólido: RAM reservada, tus propias tablas de páginas, tu propio planificador y un dispositivo de swap que el host no puede reclamar cuando un vecino tiene un pico. Ejecuta fio --name=t --size=1g --rw=randread --bs=4k en ambos modelos con cada uno inactivo y gana el contenedor; ejecuta la misma prueba mientras un vecino compila y el resultado se invierte.

La razón es la contabilidad, no la magia. Un contenedor es un conjunto de procesos con un crédito de ráfaga; un invitado KVM es una máquina con un mapa de memoria. Cuando el host entra bajo presión, el pool del contenedor se encoge de forma invisible mientras el del invitado no, así que el benchmark en el que no puedes confiar bajo carga estaba midiendo lo equivocado desde el principio. Compara trazas de vmstat 1 de ambos modelos durante una compilación y la diferencia deja de ser teórica en un par de minutos.

El error habitual es elegir un plan desde la tabla de un sitio de comparativas y descubrir la arquitectura después de la migración. Compruébalo antes de que aterricen los datos: en una máquina de kernel compartido, uname -r muestra la cadena de compilación del proveedor y ls /dev/kvm falla. En una porción KVM el dispositivo existe, la cadena del kernel es tuya y la diferencia está a un comando de distancia. Diez segundos de comprobación ahora, o una re-plataformización completa más adelante cuando la carga de trabajo supere la ficción.

La virtualización completa no es más rápida; es predecible, y la predictibilidad es lo que la producción compra realmente. Todo lo que un plan de contenedores no puede prometer se deriva del mismo muro: memoria honesta, un kernel elegido, swap real e imágenes fuera de la familia Linux. Las secciones siguientes toman esas promesas de una en una, con los modos de fallo de la alternativa adjuntos a cada una, porque la comparación solo significa algo cuando ambos lados fallan con honestidad.

Kernel compartido significa que el host puede reclamar lo que el panel llamó tuyo

Las cifras del panel en los planes de contenedores describen un pico, no una posesión. OpenVZ y LXC contabilizan la memoria como un pool de ráfaga que el host reclama cada vez que un vecino tiene un pico, lo que significa que los 2 GB que anuncia tu plan son un techo que puedes tocar y un suelo que no puedes conservar. La virtualización completa lo invierte: las páginas reservadas siguen siendo tuyas, y la presión de otros inquilinos se detiene en la frontera del hipervisor en lugar de dentro de tu base de datos.

El reclamo tiene una firma que puedes aprender a leer. En un host de kernel compartido bajo estrés, el crédito de ráfaga desaparece primero, luego el kernel empieza a buscar víctimas, y el OOM killer elige según su propia puntuación — por eso la víctima suele ser tu base de datos y no el vecino ruidoso. En un invitado KVM, la misma presión produce líneas de dmesg | grep -i oom solo cuando tu propio uso excede realmente tu propio límite, y el comportamiento de overcommit del kernel sigue las reglas que tú estableces, como describe la documentación de overcommit del kernel para la máquina que de verdad administras.

La memoria honesta también cambia el ajuste fino. Un invitado con 4 GB reservados puede ejecutar InnoDB con un buffer pool del tamaño correcto, fijar vm.swappiness a tu gusto y confiar en que las cifras seguirán siendo válidas mañana por la mañana. Sobre un pool de ráfaga, los mismos ajustes describen un experimento de laboratorio, porque el denominador cambia bajo tus pies sin aviso. La planificación de capacidad en un contenedor es una previsión sobre otras personas; en KVM es aritmética solo sobre ti. Esa es toda la diferencia, expresada como regla de dimensionamiento.

El error es fiarse del gráfico del panel por encima del testimonio del propio kernel. Los paneles muestrean con educación; la presión de memoria deja recibis. Tras cualquier misterio de rendimiento en un plan de contenedores, lee /proc/user_beancounters donde exista y el historial de OOM donde no, y la historia normalmente se escribe sola: crédito agotado, víctima elegida, base de datos eliminada a las 4 de la madrugada. KVM elimina el género entero, no solo una instancia del mismo, y por eso cada plan de este catálogo es virtualización completa.

La memoria reservada es la primera promesa estructural; la segunda es el propio kernel. Qué versión corre, qué módulos se cargan y qué sysctls existen son los siguientes muros contra los que chocan los contenedores, y la siguiente sección sigue la cadena de versión para mostrar por qué la diferencia se acumula en lugar de desvanecerse durante la vida de un servidor.

La versión del kernel que recibes es el kernel que conservas

En un plan de contenedores, el número de versión más importante de tu servidor no es tuyo. El kernel del host del proveedor decide qué funciones de cgroup existen, qué helpers de BPF están disponibles, qué módulos de iptables se cargaron y qué sysctls tienes permitido tocar — y ningún volumen de tickets cambia un kernel que otros inquilinos comparten. La cadena de versión es una decisión que tomó el proveedor, quizá hace años, por razones que nunca involucraron tu stack.

Un invitado KVM arranca lo que tú instales: el kernel de la distro, una compilación personalizada, un módulo out-of-tree compilado mediante DKMS. WireGuard levanta con modprobe wireguard exactamente como asume la guía rápida del proyecto; las herramientas BPF van a la par con tu userland porque bpftool version y el kernel en ejecución salen del mismo tren de versiones; los parches de seguridad llegan cuando tú los aplicas, no cuando llega la ventana de mantenimiento del host. La documentación BPF del kernel publica las interfaces, y sobre tu propio kernel finalmente posees ambos lados de ese contrato.

Esto importa más en los bordes de la matriz de compatibilidad. Un stack que necesita una función reciente de nftables, una sonda eBPF o un módulo que el proveedor nunca habilitó sencillamente no se despliega sobre un kernel compartido, y el fallo aparece como un símbolo ausente en un log a la peor hora posible. Sobre tu propio kernel, el mismo stack es una instalación de paquete, porque la ABI deja de ser la hoja de ruta de otro y se convierte en tu plan de versiones.

El error clásico es migrar una aplicación a un plan de contenedores y chocar con el muro en pleno incidente: el módulo de netfilter ausente, el controlador de cgroup en solo lectura, el kernel demasiado antiguo para el parche que tu proveedor publicó ayer. Comprueba la versión antes de la migración con uname -r frente a los requisitos documentados de la aplicación, y carga los módulos que necesitarás con modprobe mientras lo que está en juego es una máquina de laboratorio, y no un día de lanzamiento con usuarios mirando.

Poseer el kernel significa poseer también el comportamiento del planificador bajo presión de memoria, que es donde entra el swap real. La diferencia entre degradar con elegancia y morir con estrépito es el siguiente muro contra el que chocan los contenedores, y la siguiente sección lo recorre con el vocabulario de las operaciones que de verdad ocurren a las 3 de la madrugada.

El swap convierte un pico de memoria en latencia en lugar de en un funeral

Los planes de contenedores rara vez te dan swap real, y el texto de ventas lo llama una ventaja. No lo es. Sobre un pool de ráfaga, agotar la memoria significa que llega el OOM killer del kernel y elige un proceso al que disparar — normalmente el que mantiene abiertas las conexiones, es decir, el que tus usuarios estaban usando activamente. Un invitado KVM con un dispositivo de swap real degrada primero a latencia y solo muere más allá de eso, lo que cambia la forma de cada mala noche.

La mecánica no tiene glamour pero es decisiva. El swap extiende la memoria utilizable del invitado al coste de latencia de acceso para las páginas más frías, así que un pico que sería una muerte seca se convierte en un período lento que puedes atravesar. Obsérvalo con swapon --show y vmstat 1: las columnas si y so suben, los tiempos de respuesta crecen, y tienes minutos para actuar en lugar de un cadáver que reanimar. Ajusta el equilibrio con sysctl vm.swappiness=10 en servidores de base de datos que prefieren RAM antes que swap y estabilidad antes que ambos.

El swap real también hace honesta la memoria en la otra dirección: el kernel puede paginar a disco las cachés inactivas de la aplicación que olvidaste, manteniendo residente el working set de la aplicación que te importa. En un contenedor sin swap no existe esa válvula — la presión se convierte directamente en muertes, y la elección de víctima del kernel refleja su puntuación, no tus prioridades. Esa asimetría es la razón por la que los contenedores sobrevendidos fallan de noche, cuando los trabajos por lotes se acumulan y nadie está mirando las gráficas.

El error es desactivar el swap en una máquina KVM porque un foro dijo que los discos modernos lo hacen innecesario, y luego enfrentarse a una tormenta de generación de miniaturas o a un pico de restauración de copias sin válvula alguna. Dimensiona el swap entre la mitad y el total de la RAM para servidores generales, mantén swapon --show en el runbook, y alerta sobre la tasa de swap-in en lugar del uso bruto de swap — el uso es una reserva que permanece en silencio, mientras que la actividad es el síntoma de que algo necesita atención hoy.

Memoria y kernel son las promesas de ejecución. Las siguientes tratan sobre lo que puede arrancar en absoluto: imágenes fuera de la familia Linux y virtualización de hardware dentro del invitado. Ambas son propiedades estructurales del tipo de virtualización y no características que solicitar, y ambas cambian lo que una porción alquilada puede llegar a ser a lo largo de su vida.

Arrancar tu propia ISO es estructural, no un ticket de soporte

Windows en un VPS, FreeBSD en un cortafuegos, una distro de nicho con dos usuarios — las tiendas de contenedores no pueden vender nada de eso, ni a ningún precio, porque un kernel compartido ejecuta un único sistema operativo y el proveedor lo eligió hace años. La virtualización completa entrega la máquina a un bootloader, así que la cuestión de la imagen se convierte en una cuestión de soporte con una respuesta aburrida: si arranca sobre hardware virtual, arranca aquí.

El alcance práctico es más amplio que la familia Linux. Las imágenes BSD ejecutan sus propios kernels de forma nativa; Windows corre bajo la interfaz de máquina virtual de KVM con los controladores que el proyecto KVM documenta; las ISO de rescate, los diagnósticos de los fabricantes de hardware y los instaladores personalizados se acoplan todos de la misma manera. Verifica la integridad con md5sum contra la suma del editor antes de subir, monta la ISO, y el instalador que ya conoces aparece en una consola que controlas. Nada aguas arriba necesita dar su acuerdo, y no se cruza ningún ticket.

El soporte de ISO personalizadas también cambia la recuperación ante desastres. Una máquina que arrancará tu imagen de rescate te permite montar, hacer fsck y reparar un sistema de archivos sin un ingeniero de soporte en el bucle, a la hora que el fallo elija llegar. En un contenedor no hay paso de arranque que secuestrar — la recuperación significa la caja de herramientas del proveedor y su cola, a su ritmo. La diferencia en el tiempo medio de reparación es la diferencia entre poseer una máquina y alquilar un proceso, y se manifiesta exactamente cuando la necesitas.

El error es asumir que un proveedor de contenedores puede añadir una imagen exótica a petición — no puede, estructuralmente, y la negativa cortés que recibes es una descripción exacta de la arquitectura, no una elección de política. Antes de comprometerte con un plan para un sistema operativo poco común, pregunta qué imágenes arrancan en el nivel que compras y confirma que el archivo de dispositivo existe con ls -l /dev/kvm. Un comando resuelve para siempre la cuestión de la arquitectura, antes de que ningún dato esté en movimiento.

El mismo hardware virtual que arranca cualquier imagen puede, en los niveles VPS de aquí, arrancar un segundo invitado dentro del primero — virtualización anidada, y la siguiente sección trata la porción como un banco de laboratorio en lugar de un servidor de propósito único, que es la propiedad que los desarrolladores preguntan primero y menos notan hasta que la necesitan.

La virtualización anidada convierte el VPS en un banco de laboratorio

La propiedad extraña de un VPS KVM es que también puede hacer de hipervisor. La virtualización anidada permite al invitado ejecutar sus propias VMs: un laboratorio de Kubernetes de tres nodos, una máquina de pruebas con Windows, una imagen de router — todo dentro de una porción en el escalón más bajo de la escalera. Los planes de contenedores no pueden ofrecer esto en ningún nivel, porque el kernel compartido no tiene ninguna extensión de virtualización que traspasar a nadie.

Comprueba la capacidad antes de planificar en torno a ella: grep -cE 'vmx|svm' /proc/cpuinfo cuenta las banderas de virtualización expuestas a tu invitado, y lsmod | grep kvm muestra los módulos cargados en tu kernel. Con KVM anidado disponible, instala un segundo hipervisor dentro y arranca imágenes invitadas exactamente como lo harías en metal — la documentación de nested-VMX del kernel mantiene la matriz de qué se anida limpiamente y qué no. La advertencia honesta es el rendimiento: la E/S anidada paga el doble de coste de virtualización, así que dimensiona discos y expectativas en consecuencia desde el primer experimento.

El caso de uso de laboratorio es donde esto se paga solo de inmediato. Una matriz de CI que necesita tres máquinas limpias por ejecución, una demostración de clase de clustering, un espejo de staging de una topología de producción — cada uno está a un archivo de configuración de distancia en lugar de a un pedido de hardware. Haz snapshots de los invitados del laboratorio, reconstrúyelos desde el código, y el entorno deja de ser una mascota. En un plan de contenedores, el mismo experimento empieza con un correo a ventas y normalmente acaba ahí, por eso los laboratorios acaban viviendo sobre virtualización completa.

El error es tratar a un invitado anidado como capacidad de producción. Es un banco: correcto para compilaciones, pruebas y demostraciones, equivocado para cualquier cosa cuya SLA respondas con tu nombre. Deja la capa anidada para trabajo desechable, mantén holgura en los recursos de la porción exterior, y recuerda que qemu-system-x86_64 dentro de tu VPS compite con tus propios servicios por los mismos núcleos reservados. La reserva es tuya para gastarla dos veces en el papel; los núcleos mismos no.

Entre el kernel, el dispositivo de swap, las imágenes arrancables y el hipervisor anidable, una porción KVM es una máquina pequeña en el sentido pleno de la palabra. La siguiente pregunta es la que los desarrolladores hacen primero en la práctica: ¿y los contenedores mismos, ejecutándose de la manera corriente, como lo hacen en un portátil?

Docker en una VM completa se comporta como Docker en metal

Docker dentro de un VPS basado en contenedores son contenedores hasta el fondo, y las costuras se notan: versiones de cgroup solapadas, sysctls enmascarados, trucos de red que funcionan a medias por razones que nadie puede explicar dos veces. Docker dentro de un invitado KVM es simplemente Docker sobre tu propio kernel — sin restricciones, sin máscaras e indistinguible de tu portátil. La distinción suena académica hasta que el primer stack de Compose se niega a arrancar por causas que el mensaje de error no puede nombrar.

Todo lo normal funciona: el motor se instala desde la documentación oficial, docker compose up -d levanta el stack, los bind mounts se comportan, y la red en bridge obtiene su propio namespace con netfilter real por debajo. El almacenamiento de contenedores es la única partida de presupuesto a vigilar — las imágenes y los volúmenes aterrizan en tu NVMe, y docker system df es el comando que dice la verdad sobre cuántos de los 80 GB del nivel de entrada está reteniendo como rehenes, en silencio, la caché de compilación esta semana.

El modelo KVM además elimina la capa de permisos que algunos hosts de contenedores imponen. No hay paso de pídele-al-proveedor para un contenedor privilegiado, una red personalizada o un módulo del kernel que el stack quiera cargar primero: modprobe, luego docker run, y el módulo está ahí para cada contenedor que venga después. Esa única propiedad es la razón por la que los runners de CI, las imágenes de VPN y los agentes de monitorización que necesitan eBPF sencillamente funcionan aquí y fallan en otros lugares de forma silenciosa y misteriosa — el kernel responde ante ti, y el contenedor habla con el kernel.

El error clásico es dejar que las imágenes se acumulen hasta que el disco se llena y la base de datos empieza a rechazar escrituras — la basura de Docker es silenciosa hasta que es ruidosa, y entonces es muy ruidosa. Pon docker system prune en un calendario, guarda los datos en volúmenes con nombre en lugar de anónimos, y revisa el overlay antes de cada actualización importante. Cuando la carga de trabajo supere de verdad cualquier porción, toma el dedicated Forge a $49/mes de lista — $39.20/mes anual-efectivo — y ejecuta los mismos stacks sobre 2 x 1 TB NVMe exclusivos con IPMI detrás.

Los contenedores son la carga de trabajo; el tipo de virtualización decide si corren como invitados o como prisioneros. La última cuenta es el precio: lo que cuesta la virtualización completa en la etiqueta, y lo que elimina de la columna de riesgo — porque las dos columnas nunca se equilibran como sugieren las tablas comparativas, y la diferencia es toda la decisión.

Lo que cuesta la virtualización completa, y lo que elimina

La columna de costes honesta para KVM dice: unos pocos por ciento en microbenchmarks, unos pocos megabytes para el kernel del invitado y un tiempo de arranque medido en segundos. La columna de créditos honesta dice: tu propio kernel, RAM ECC reservada, swap real, cualquier imagen arrancable, virtualización anidada y Docker sin capa de permisos. El catálogo precia el paquete entero como si el hipervisor fuera gratis, porque operativamente casi lo es.

La escalera VPS de tres niveles va desde el nivel de entrada de 2 vCPU / 4 GB pasando por 8 GB hasta el 8 vCPU / 32 GB de la gama alta, con KVM en cada escalón, puertos sin límite de tráfico a 1/2.5/10 Gbps, y el plazo anual restando un 20 por ciento. Pide Core a $6/mes de lista — $4.80/mes anual-efectivo — y el kernel, el dispositivo de swap y el mapa de memoria son tuyos por construcción y no por política. El tipo nunca aparece como un upsell porque no hay nada más barato desde lo que actualizar; el muro es equipamiento estándar.

Lo que el tipo elimina es un género de incidente, y el género es la parte cara. Ni un crédito de ráfaga que se esfuma en la hora del cron del vecino, ni un OOM killer puntuando tu base de datos contra la page cache de otro, ni un módulo que el proveedor nunca compiló, ni un sistema operativo que la plataforma no puede arrancar. Esos son resultados arquitectónicos de los kernels compartidos, no rarezas de un mal proveedor — y la misma lógica de aislamiento que amuralla la memoria aparece en el borde de red, cubierta en la guía de filtros DDoS y gestión de abusos.

El error en la otra dirección es pagar por aislamiento que no usarás: un sitio estático o una caja de cron va bien en casi cualquier cosa, y el escalón más barato de casi cualquier cosa sirve. Ajusta el tipo al fallo que no puedes permitirte. Bases de datos, correo, CI, cualquier cosa con estado — ahí es donde se concentran los modos de fallo de los contenedores de las secciones anteriores, y donde el muro gana su pequeño porcentaje cada mes sin aparecer en ninguna factura.

Decide el tipo una vez, antes de que aterricen los datos, porque migrar a través de la frontera más adelante significa una instalación limpia y una copia, con toda la planificación que eso implica. La sección final comprime toda la decisión en el orden en que ejecutarla, desde el primer comando en una máquina vacía hasta el momento en que la carga de trabajo gana tu confianza.

La comprobación de virtualización, en el orden de ejecución

Ejecuta la comprobación antes de pedir, primero sobre el papel. Enumera lo que debe arrancar: imágenes de sistemas operativos, módulos del kernel, invitados anidados, el stack de Compose con sus contenedores privilegiados. Cualquier cosa de esa lista que un kernel compartido no pueda entregar estructuralmente — BSD, Windows, kernels personalizados, modprobe a voluntad — resuelve la cuestión del tipo antes de que entre el precio, que es el único orden que sobrevive al contacto con una carga de trabajo real.

Los primeros 10 minutos en la máquina nueva confirman la compra. uname -r debe mostrar una cadena de kernel que reconoces y puedes cambiar; ls -l /dev/kvm debe mostrar el dispositivo de virtualización, presente y con dueño; swapon --show debe listar un dispositivo de swap real; free -m debe mostrar la RAM que el plan prometió, reservada y entera. Cuatro comandos, diez segundos cada uno, y la arquitectura queda verificada en lugar de supuesta desde una tabla comparativa.

Luego carga la máquina como la cargará la producción, porque las diferencias entre tipos solo aparecen bajo presión. Ejecuta la prueba de almacenamiento con fio, observa el comportamiento de la memoria con vmstat 1, y compila algo grande mientras corren las pruebas. Lo que buscas es la ausencia de sorpresas: ni pools reclamados, ni vecinos invisibles, ni líneas OOM de dmesg | grep -i oom que tu propio uso no pueda explicar. Una máquina que es honesta inactiva y honesta bajo carga es honesta, y punto.

Configura después el runtime: Docker desde la documentación oficial, los módulos que necesita tu stack, los sysctls que quiere la base de datos, cada uno aplicado y luego anotado en el runbook. Es también el momento de fijar el dimensionamiento del swap y la swappiness de la sección anterior, mientras no hay datos que migrar ni usuarios que molestar. Todo lo que configuras antes de que aterricen los datos es una decisión; todo lo que viene después es un riesgo.

Solo ahora se mueven los datos, y solo después de probar la primera restauración. Migra en el orden corriente — archivos, base de datos, configuración, DNS al final — y mantén el entorno antiguo intacto hasta que el nuevo haya sobrevivido a una semana completa incluyendo su primer ciclo de copias de seguridad. Si algún paso de esta secuencia te sorprende, te sorprendió mientras lo que estaba en juego era un laboratorio; para eso existe la secuencia, y por eso la cuestión del tipo va siempre primero.