KVM vs. OpenVZ vs. LXC: qué te permite hacer realmente el tipo de virtualización de tu VPS

Dos planes de VPS, la misma página. Cuatro vCPU, 8 GB de RAM, 160 GB de almacenamiento, precio casi idéntico. Uno dice KVM. El otro dice OpenVZ. Ninguna de las dos páginas explica qué cambia esa palabra.

Cambia lo que se te permite ejecutar. Los tipos de virtualización de VPS no son una simple nota al pie sobre rendimiento. Deciden si controlas el kernel, si Windows es posible y si Docker funciona sin ayuda del proveedor. KVM vs. OpenVZ vs. LXC es una cuestión de capacidades antes que de velocidad.

Esta guía cubre las tres etiquetas más relevantes para esta decisión de compra. Xen, VMware, Hyper-V y otras plataformas de virtualización existen, pero quedan fuera de esta comparación a tres bandas.

TL;DR

• KVM da a cada VPS su propio kernel invitado. Docker funciona con normalidad, Windows es técnicamente posible y por lo general puedes cargar módulos del kernel o arrancar un kernel personalizado. Sin embargo, KVM por sí solo no garantiza CPU ni RAM dedicadas; los compromisos de recursos siguen dependiendo del proveedor y del plan.
• OpenVZ los planes de VPS son normalmente contenedores Linux que comparten el kernel del host. Docker solo puede funcionar en OpenVZ 7 cuando el proveedor usa un kernel y una configuración de plantilla compatibles. No puedes reemplazar el kernel del host, y la memoria más allá de la RAM se gestiona mediante VSwap controlado por el proveedor en lugar del swap de disco habitual gestionado por el invitado.
• LXC también comparte el kernel del host, pero está construido sobre las funciones de contención del Linux principal. Docker puede funcionar cuando el host habilita las funciones necesarias, aunque Proxmox recomienda anidar los contenedores dentro de una máquina virtual QEMU para cargas que necesitan aislamiento máximo y migración en caliente.
• Los contenedores suelen ser más fáciles de redimensionar en caliente. KVM también puede admitir el hot-plug de CPU y memoria, así que "KVM siempre exige reiniciar" no es una regla de compra fiable. Pregunta al proveedor qué admite realmente su plataforma.
• Para un sitio estático o una pila LAMP pequeña que nunca necesita Docker, Windows ni personalización a nivel de kernel, la diferencia práctica puede ser pequeña. El aislamiento, el ciclo de vida y la política de recursos aún pueden variar.

La única diferencia que provoca todas las demás

KVM da a cada VPS del host su propio kernel invitado. Los contenedores OpenVZ y LXC usan el kernel que arrancó el host.

KVM es una solución de virtualización completa para hardware x86 con extensiones de virtualización. Se integró en el kernel principal de Linux a partir de la versión 2.6.20. Cada invitado ve hardware virtual y arranca su propio sistema operativo y su propio kernel.

Los tipos de contenedor funcionan de otra manera. LXC es una interfaz de espacio de usuario para las funciones de contención del kernel de Linux, incluidos namespaces, cgroups, capabilities, seccomp y perfiles de seguridad. Su objetivo es ofrecer un entorno parecido a una instalación normal de Linux sin arrancar un kernel aparte.

Un contenedor OpenVZ sigue el mismo modelo general de kernel compartido, aunque OpenVZ usa su propia plataforma y su propia pila de kernel. OpenVZ 7 puede gestionar tanto contenedores como máquinas virtuales KVM, pero cuando un plan de VPS comercial se etiqueta como "OpenVZ", el producto que se vende normalmente es el tipo contenedor.

Todas las diferencias de capacidades que siguen se derivan de ahí. Un módulo del kernel debe cargarse en un kernel que tú controles. Un sistema operativo distinto necesita un kernel distinto. Docker necesita espacios de nombres a nivel de kernel, que deben estar disponibles allí donde reside el propio kernel. Del lado de KVM de esa frontera, la capa del hipervisor sigue una arquitectura que suele dividirse en hipervisores de tipo 1 y de tipo 2.

LXC aparece con frecuencia en entornos Proxmox, incluidos servidores autogestionados y algunas plataformas de hosting. Que puedas habilitar funciones avanzadas de LXC depende de quién controle ese host.

LEER

KVM vs. OpenVZ 2022: ¿quién es el genio de la virtualización?

Qué te permite ejecutar cada tipo

Los ejes que definen la compra son el control del kernel, la compatibilidad con el sistema operativo invitado, la compatibilidad con Docker, el comportamiento de la memoria, el redimensionado y la política de recursos.

¿Cuál deberías elegir? KVM es la respuesta más clara cuando necesitas Windows, un kernel personalizado, módulos cargados por el invitado o un host Docker predecible. OpenVZ y LXC pueden ser entornos Linux eficientes, pero dejan las decisiones a nivel de kernel en manos del proveedor.

Esto es un mapa de capacidades, no un benchmark. No dice nada sobre la latencia del almacenamiento, la calidad de la red, la generación de CPU, la ocupación del host ni la política de asignación de recursos del proveedor. Dos proveedores con el mismo tipo de virtualización pueden entregar máquinas muy distintas.

En las celdas condicionales es donde los compradores pierden tiempo. Una vez desplegué una VPN en un VPS en contenedor donde la función de red necesaria del lado del host no estaba expuesta. La interfaz no levantaba, y la solución exigió un ticket de soporte en lugar de un cambio de configuración dentro del invitado. Con un plan en contenedor, pregunta si el proveedor expone exactamente el dispositivo o la función de kernel que tu VPN necesita. Con KVM, normalmente controlas eso dentro del invitado.

Por qué Docker es la pregunta que decide la mayoría de las compras

VPS en contenedor frente a VPS KVM deja de ser una comparación abstracta en cuanto Docker aparece en tus requisitos. El propio Docker usa namespaces del kernel, cgroups, red y controladores de almacenamiento. Dentro de KVM, esas funciones pertenecen al kernel invitado que tú controlas. Dentro de OpenVZ o LXC, dependen en última instancia del host.

Docker en OpenVZ

La compatibilidad con Docker en OpenVZ es una decisión de aprovisionamiento que se toma por encima de ti. Un artículo de soporte de SolusVM afirma que Docker puede ejecutarse dentro de OpenVZ 7 a partir de una versión concreta del kernel 3.10, pero también dice que Docker no funciona con las plantillas precreadas heredadas estándar. El contenedor debe usar una plantilla EZ o una plantilla personalizada adecuada. Ese mismo artículo excluye los invitados CentOS 8.

Entonces, ¿funciona Docker en OpenVZ? A veces. El proveedor debe haber construido el servicio en torno a un kernel OpenVZ 7 compatible y a una ruta de plantillas adecuada. Si la página del plan no lo indica con claridad, pregunta al soporte antes de comprar y guarda la respuesta por escrito.

Cuando la configuración del host es incompatible, cambiar los flags de Docker dentro del VPS no arreglará el problema de fondo. Necesitas que el proveedor cambie la configuración del contenedor o te traslade a otro tipo de virtualización.

Docker en LXC

Docker puede ejecutarse dentro de LXC cuando el host expone las funciones necesarias. En Proxmox, eso suele incluir el anidamiento de contenedores y keyctl para contenedores sin privilegios.

La señal de compra más importante es la recomendación del responsable de la plataforma. La documentación de Proxmox indica que anidar contenedores dentro de una VM QEMU de Proxmox sigue siendo una práctica recomendada para casos de uso que exigen aislamiento máximo y migración en caliente, en lugar de ejecutarlos directamente en un contenedor de sistema LXC.

Si controlas el host LXC, puedes evaluar ese compromiso y probar las actualizaciones a tu propio ritmo. Si alquilas un VPS LXC, el proveedor controla el kernel, el perfil de seguridad y los flags de funciones avanzadas. Confirma la configuración admitida en lugar de suponer que basta con tener acceso root dentro del contenedor.

Docker en KVM

Docker funciona normalmente porque el invitado Linux controla su propio entorno de kernel. No hay ningún interruptor de anidamiento LXC ni requisito de plantilla OpenVZ por encima del invitado. Aun así necesitas una distribución Linux compatible, un kernel compatible y suficiente RAM y almacenamiento para la carga de trabajo.

Ser dueño del kernel invitado también implica mantenerlo. En un VPS no gestionado, las actualizaciones, las reglas de firewall, la seguridad de Docker y las copias de seguridad siguen siendo responsabilidad tuya.

Conclusión clave: Docker no hace imposibles OpenVZ ni LXC, pero convierte la configuración del proveedor en parte de la fiabilidad de tu aplicación. Para un host Docker de producción alquilado, KVM elimina esa dependencia adicional.

Si "4 vCPU" significa cuatro núcleos de CPU dedicados

Un VPS que se siente lento mientras su propia monitorización muestra la CPU inactiva es el síntoma que más se describe. La virtualización por contenedores es lo que lo hace posible. La contención ocurre una capa por debajo de lo que el invitado puede ver, así que sus propias métricas no muestran nada raro.

El mecanismo es la baja sobrecarga en sí. Un contenedor le cuesta al host mucho menos que una máquina virtual completa, así que caben más contenedores en el mismo hardware. Esa densidad es barata de crear y difícil de detectar desde dentro del invitado, lo que hace que la sobreventa sea estructuralmente más fácil en OpenVZ que en KVM. KVM no impide que un proveedor apiñe un host. Pero sí compromete memoria real y cuotas reales de CPU por invitado, lo que pone un techo aritmético a cuánto se puede apiñar. El lado del diagnóstico tiene su propia guía sobre cómo saber si tu proveedor está sobrevendiendo.

La memoria también se comporta de otra manera. En OpenVZ no puedes usar el swap de disco como memoria adicional, así que la cifra de RAM de la página del plan es un muro, no una pendiente. Un invitado KVM bajo presión de memoria se ralentiza. A un contenedor OpenVZ bajo presión de memoria le matan procesos.

También hay una consecuencia en el aislamiento, y es la que más se subestima. La memoria de un contenedor es direccionable desde el host de un modo en que la de un invitado KVM no lo es. El cifrado de disco dentro del invitado sigue protegiéndote frente a un disco robado. No protege las claves de un contenedor en ejecución frente a la máquina que lo está ejecutando. Si tu modelo de amenazas incluye al operador del host, un kernel compartido es el sustrato equivocado. Ninguna configuración dentro del invitado cambia eso.

Conclusión clave: la misma cifra en una página de plan es una promesa distinta según el tipo. En KVM es una asignación. En OpenVZ es un techo que compartes.

Dónde OpenVZ sigue teniendo sentido y hacia dónde va

Si ejecutas un sitio estático o una pila LAMP de poco tráfico, quizá nunca toques las capacidades que OpenVZ restringe. Nada de Windows, ni kernel personalizado, ni módulos cargados por el invitado, ni Docker en producción. Para esa carga de trabajo tan concreta, un contenedor OpenVZ bien gestionado todavía cumple.

El ciclo de vida exige más atención que hace una década. OpenVZ 7 se basa en la rama del kernel de RHEL 7, versión 3.10. El número de versión por sí solo no demuestra que a un kernel empresarial mantenido le falten parches de seguridad, porque los proveedores hacen backport. Sí implica que deberías verificar la compatibilidad con software que espera interfaces de kernel más recientes.

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the política oficial de ciclo de vida.

Eso no rompe hoy un sitio OpenVZ que funciona. Pero sí hace relevante el plan de migración del proveedor antes de que comprometas una nueva carga de trabajo de larga vida. Pregunta qué versión de OpenVZ o Virtuozzo está en marcha, cómo se entregan las correcciones de seguridad y qué ruta de migración existe.

Cuando la página de un plan no nombra el tipo de virtualización, pregunta al soporte en lugar de deducirlo del precio. Vale la pena tener la respuesta por escrito.

Elegir según la carga de trabajo

Parte del requisito, no de la tecnología.

Elige KVM cuando la carga de trabajo necesite su propio kernel

KVM es la opción directa cuando necesitas cualquiera de estas cosas:

• Windows como sistema operativo invitado
• Un kernel personalizado
• Módulos del kernel cargados por el invitado
• Docker en producción sin dependencias de contenedor dentro de contenedor
• Virtualización anidada, cuando el proveedor la expone
• Swap y ajuste del kernel controlados por el invitado

Windows es decisivo porque tanto los contenedores OpenVZ como los LXC usan un kernel de host Linux. Elegir entre Linux y Windows para la aplicación en sí es otra cuestión, con temas de compatibilidad de software, administración y licencias. Consulta la comparación entre VPS Linux y Windows para esa decisión.

Elige LXC cuando quieras un contenedor de sistema Linux eficiente

LXC es razonable cuando la carga de trabajo es solo Linux, no necesita un kernel aparte y se beneficia de poca sobrecarga o de cambios rápidos gestionados por el host. Resulta especialmente útil cuando controlas tú mismo el host de Proxmox o LXC.

Para un VPS LXC alquilado, verifica la compatibilidad con Docker, los dispositivos necesarios, el modo de seguridad, el comportamiento de las copias de seguridad y si se pueden habilitar funciones avanzadas.

Considera OpenVZ para una carga Linux sencilla y verificada

OpenVZ todavía puede ser aceptable para un sitio web básico, una pila LAMP pequeña, un servicio DNS o una carga Linux igual de convencional, siempre que:

• El proveedor documenta la versión de la plataforma.
• Tu software es compatible con el entorno de kernel disponible.
• No necesitas Windows ni personalización del kernel.
• Docker o no hace falta, o está explícitamente soportado.
• El proveedor tiene un plan creíble de seguridad y migración.
• El precio o el modelo operativo te da una razón real para elegirlo.

No lo elijas solo porque una comparación antigua diga que OpenVZ siempre es más barato. Compara el plan actual, el soporte, la política de recursos y las opciones de migración.

Si tu respuesta acabó siendo KVM, es la restricción la que decide, no una preferencia. El Servidor privado virtual KVM de Cloudzy arranca en 60 segundos sobre AMD EPYC con NVMe puro, y cada instancia recibe su propio kernel invitado. Los módulos del kernel se cargan, los kernels personalizados arrancan, y se admiten invitados tanto Linux como Windows. Docker está en el marketplace si prefieres no instalarlo tú mismo.

Preguntas frecuentes

systemd-detect-virt