Contenedores LXC frente a VMs KVM en Proxmox: cuándo usar cada uno

La respuesta primero: tres preguntas lo deciden

Para cualquier workload, pregúntate:

1. ¿Necesita su propio kernel? Un sistema operativo distinto (Windows, BSD), una versión de kernel concreta, módulos de kernel, o un ajuste profundo del kernel → VM. Los contenedores comparten el kernel del host, sin excepción.
2. ¿Cómo de fuerte debe ser el aislamiento? Código no confiable, separación entre tenants, límites de cumplimiento normativo → VM. El límite de la virtualización por hardware es categóricamente más fuerte que el aislamiento por namespaces.
3. ¿Necesitarás moverlo sin detenerlo? La migración en caliente entre nodos de un clúster es exclusiva de las VMs; los contenedores se mueven mediante parada y reinicio.

Si las tres respuestas son "no" (un servicio confiable, basado en Linux, reiniciable), un contenedor LXC te da el mismo workload en una fracción de la huella, y arranca en aproximadamente un segundo. Eso describe buena parte de la infraestructura real: reverse proxies, DNS, herramientas internas, instancias de servicio por aplicación. Por eso el patrón práctico en Proxmox es mixto: VMs para las joyas de la corona y todo lo ajeno, contenedores para la flota de pequeños servicios Linux que las rodean.

Cómo funciona cada uno realmente

Una VM KVM es un ordenador completo en software: QEMU presenta hardware virtual, KVM (el módulo hipervisor del kernel) ejecuta el código del invitado con aceleración por hardware, y el invitado ejecuta su propio kernel sobre ese hardware, desde su propia imagen de disco. El host ve un solo proceso; el invitado, en la práctica, no sabe que está virtualizado (casi: los drivers paravirtualizados de VirtIO existen precisamente para que coopere en aras de la velocidad).

Un contenedor LXC no es un ordenador: es una vista particionada del kernel del host. Los namespaces le dan árboles de procesos, pilas de red y sistemas de archivos privados; los cgroups miden su consumo de CPU y memoria. No hay un segundo kernel, ni hardware virtual, ni más proceso de arranque que iniciar init. Por eso un contenedor arranca en un segundo y añade un overhead por instancia prácticamente nulo, y por eso cada contenedor del host vive y muere con el único kernel de ese host.

Proxmox trata a ambos como ciudadanos de primera: la misma interfaz, los mismos backends de almacenamiento, las mismas copias de seguridad vzdump/PBS, el mismo flujo de firewall y snapshots. Las diferencias que siguen son inherentes a las tecnologías, no limitaciones de Proxmox.

Densidad y overhead: la versión honesta

Proxmox no publica ninguna cifra oficial del tipo "X contenedores por VM equivalente", y deberías desconfiar de cualquiera que lo haga: la densidad depende por completo del workload. Pero el mecanismo no es discutible y merece la pena entenderlo:

• Cada VM paga un impuesto fijo: su propio kernel y procesos de sistema, más su memoria asignada, que queda reservada la use el invitado o no (el ballooning recupera algo, de forma imperfecta). Veinte VMs pequeñas significan veinte kernels y veinte reservas de memoria.
• Veinte contenedores comparten un solo kernel y una sola page cache, y sus límites de memoria de cgroup son techos, no reservas; el RAM que un contenedor no usa es simplemente RAM libre para el host.

En trabajo limitado por CPU, la diferencia de rendimiento es pequeña: la ejecución asistida por hardware de KVM es eficiente, y una VM ocupada es casi tan rápida como un contenedor ocupado. La brecha aparece en la economía de memoria y el overhead por instancia: en un host que ejecuta muchos servicios pequeños, containerizarlos suele multiplicar cuántos caben, menos porque los contenedores sean "más rápidos" que porque las VMs reservan lo que los servicios inactivos nunca usan. Dimensiona el host en ambos casos con las reglas de virtualización de nuestra guía de dimensionamiento. El RAM es la restricción vinculante en los dos modelos.

Aislamiento: qué aporta "unprivileged", y qué no

Proxmox crea los contenedores como unprivileged por defecto, y conviene dejarlo así: el root del contenedor se mapea a un UID inofensivo y de número alto en el host, de modo que una compromisión completa del root del contenedor deja al atacante en una cuenta no privilegiada del host. Combinado con AppArmor, seccomp y cgroups, un contenedor LXC unprivileged es un límite respetable para workloads confiables.

Aun así, no es un límite de VM. Cada llamada al sistema de un contenedor llega directamente al kernel del host: la superficie de ataque entre contenedor y host es toda la interfaz del kernel, frente a la interfaz de hipervisor mucho más estrecha de una VM. Las reglas prácticas que se derivan de esto:

• Código no confiable o expuesto a internet y de alto riesgo, otros tenants, workloads separados por cumplimiento normativo → VM. Para eso está el límite más fuerte.
• Los contenedores privileged (la opción no predeterminada) debilitan bastante el planteamiento: trátalos como una vía de escape heredada, no como una opción. Si un workload "necesita" un contenedor privileged, en realidad suele querer una VM.
• Los contenedores con nesting activado (por comodidad para Docker y systemd) relajan aún más el aislamiento: aceptable para servicios internos confiables, un argumento más en contra de usarlo para algo dudoso.

La cuestión de Docker

La versión más habitual de esta comparación es en realidad "¿dónde van mis contenedores Docker?" La recomendación actual del propio Proxmox, suavizada con los años pero constante en su orientación: para producción (sobre todo donde importan el aislamiento o la migración en caliente), ejecuta Docker dentro de una VM, no dentro de un contenedor LXC. Docker en LXC (con nesting activado) es popular en homelabs porque se salta el overhead de una VM, pero apila dos runtimes de contenedores sobre un solo kernel y tiene un historial de romperse con las actualizaciones del host, el tipo de fragilidad que se acepta en un laboratorio y se lamenta en producción.

Vale la pena seguirlo mientras madura: desde PVE 9.1, Proxmox puede crear contenedores directamente a partir de imágenes OCI (el formato de imagen de Docker) como technology preview: descargas una imagen y la ejecutas como un contenedor de aplicación gestionado por Proxmox, sin ningún daemon de Docker de por medio. Es realmente prometedor como futura respuesta nativa, pero "technology preview" significa exactamente eso; la aburrida VM sigue siendo la recomendación para producción mientras esto se asienta.

Así que: una VM "host Docker" (o unas cuantas, por dominio de confianza), Docker dentro de ella, y Proxmox gestiona la VM: obtienes aislamiento de nivel VM, migración en caliente para todo el parque Docker, y actualizaciones de host limpias.

Lo que solo las VMs pueden hacer, y en qué destaca LXC

Más allá de las tres preguntas decisivas, la lista concreta de lo que solo las VMs permiten: Windows y otros invitados que no son Linux, kernels personalizados o más recientes que el del host, módulos de kernel (WireGuard ya forma parte del kernel, pero piensa en módulos de almacenamiento especializado o de investigación), passthrough PCIe vía VFIO (GPUs para transcodificación o IA, HBAs para un invitado NAS), y, operativamente el más importante, la migración en caliente y la portabilidad independiente del hipervisor (una imagen de disco de VM se traslada a cualquier host KVM; la configuración de un contenedor está más entrelazada con su host).

El terreno propio de LXC, en correspondencia: el patrón de muchos servicios pequeños. Un contenedor por servicio (DNS aquí, reverse proxy allá, un Postgres para esta app, un stack de monitorización), cada uno con capacidad de snapshot, copia de seguridad, límite de recursos y reinicio de forma independiente, a un coste por instancia lo bastante bajo como para que "un servicio, un contenedor" sea asequible como política. Los bind mounts añaden un superpoder discreto: montar directorios del host directamente dentro de los contenedores, sin necesidad de sistema de archivos de red, algo natural para un contenedor que procesa datos que viven en el gran pool ZFS del host.

Una salvedad de clúster a tener en cuenta: la "migración" de contenedores entre nodos es migración por reinicio: parar, mover, arrancar (segundos de inactividad para un contenedor ligero, pero inactividad al fin y al cabo). El HA funciona igual: los contenedores de un nodo caído se reinician en otro. Si un servicio no puede tolerar eso, pertenece a una VM. Eso es la pregunta 3 haciendo su trabajo.

La tabla de decisión

Preguntas frecuentes

¿Puedo convertir un contenedor en una VM más adelante (o al revés)?

No existe una conversión con un solo clic. El contenido del disco es compatible (son todo sistemas de archivos Linux), pero el empaquetado difiere: una VM necesita un kernel, un gestor de arranque y un init que una imagen de contenedor no lleva. La ruta práctica es volver a desplegar y migrar los datos, algo que rara vez resulta doloroso para los servicios pequeños que alojan los contenedores. Vale la pena tener presente la asimetría en el momento de desplegar: "empezar como VM, containerizar más adelante" solo cuesta recursos, mientras que "empezar como LXC, pasar a VM más adelante" cuesta una migración. Ante una duda genuina, la VM es la opción más o menos reversible.

¿Cuánto más rápido es LXC en realidad?

En cómputo puro, apenas: KVM ejecuta las instrucciones de CPU del invitado con asistencia por hardware, así que una VM de cálculo intensivo se queda a pocos puntos porcentuales de lo nativo. Las diferencias honestas: el tiempo de arranque (un segundo frente a un arranque de sistema operativo completo), la economía de memoria (techos frente a reservas: de ahí viene la densidad), y la longitud de la ruta de E/S (la E/S de un contenedor es E/S del host; la E/S de una VM atraviesa VirtIO, que es rápido pero no gratis). Si tu motivación es el "rendimiento", mide primero; si es "meter 30 servicios pequeños en una sola máquina", el caso de LXC se defiende solo.

¿Funcionan los contenedores con el HA y el clustering de Proxmox?

Sí, con una diferencia de comportamiento: sin migración en caliente. Mover un contenedor entre nodos (por mantenimiento, o por el HA tras el fallo de un nodo) funciona por parar-transferir-arrancar, así que cuenta con entre unos segundos y un minuto de inactividad por movimiento, en lugar del cambio imperceptible que reciben las VMs. Para la mayoría de los servicios de clase contenedor eso no supone un problema (y que el HA reinicie tu contenedor DNS en un nodo superviviente es mejor que dejarlo caído); donde no sea así, consulta la pregunta 3 y usa una VM. La mecánica de clúster se trata en nuestra guía de HA.

¿Debería mi configuración entera ser simplemente VMs, por simplicidad?

Es una simplificación defendible (un solo modelo, el aislamiento más fuerte en todas partes, migración en caliente para todo), y si tus servicios son pocos y el RAM abunda, adóptala. El coste es la densidad: las VMs inactivas reservan memoria que los contenedores inactivos no reservarían, así que una flota de solo VMs necesita un host más grande para el mismo workload. La mayoría de los operadores converge hacia la mezcla que describe este artículo en cuanto crece el número de servicios; no hay premio por la pureza en ninguna de las dos direcciones.

Desplegar en Serverside

Ambos modelos quieren el mismo sustrato: núcleos, RAM y NVMe rápido. Nuestros servidores dedicados Proxmox llegan preinstalados y aprovisionados en menos de un minuto sobre el ASN 55285, con suficientes opciones de RAM para ejecutar la flota de solo VMs si ese es tu estilo, redes privadas para configuraciones multinodo, y KVM-over-IP para el propio host. Dimensiona la máquina con la guía de dimensionamiento de servidores (suma tus invitados, el RAM es la restricción), y luego completa con el resto de la serie: configuración inicial, redes, y copias de seguridad.