LXC o VM en Proxmox: qué aislamiento elegir para tu homelab
La pregunta de principiante que deja al descubierto toda la filosofía de Proxmox
La pregunta parecía inocente: ¿cuándo conviene usar un LXC y cuándo una VM? Debajo estaba la inquietud con la que todo usuario nuevo de Proxmox acaba tropezando. Quien la planteó ya tenía varios servicios ligeros funcionando en LXC: Jellyfin, Pi-hole, nginx y otras piezas parecidas del rompecabezas del homelab. También tenía dos VM, una para una aplicación personal basada en Docker y otra para Home Assistant. Entonces apareció la duda. Había leído que las actualizaciones del host pueden romper los LXC porque los contenedores comparten el kernel del host, mientras que las VM son más autónomas, y de repente su pequeña arquitectura ordenada empezó a parecer arriesgada.
Es una trampa fácil. Al principio los LXC parecen la respuesta obvia porque son rápidos, ligeros y fáciles de crear. Luego alguien menciona el kernel compartido, las fugas de contenedores o las roturas tras una actualización, y el péndulo se va con fuerza al otro extremo: meterlo todo en una VM. La mayoría de los usuarios con experiencia no lo ven así. El consejo más sólido del hilo venía a decir que uses LXC por defecto para muchos servicios del homelab y recurras a una VM cuando el aislamiento, el empaquetado, las pilas de Docker o un sistema operativo especial hagan de ella la opción más limpia.
Esa respuesta solo decepciona porque no te la puedes tatuar en el rack. Es una cuestión de criterio. Proxmox te da las dos herramientas porque las dos son útiles, y el truco está en saber qué tipo de error intentas evitar en lugar de abrazar una religión.
Los LXC son ligeros, rápidos y están un poco más cerca del fuego
Es fácil enamorarse de los LXC. Son ligeros, arrancan rápido, consumen menos recursos y pueden aprovechar mejor el almacenamiento. Pueden compartir carpetas del host sin fingir que todo es un recurso compartido de red, y se llevan bien con las copias de seguridad granulares de Proxmox, los snapshots, los puntos de montaje, SDN y el tipo de distribución de servicios pequeños que suelen montar los usuarios de homelab: un Pi-hole aquí, un proxy inverso nginx allá, una instancia de AdGuard, Navidrome, quizá Immich, quizá algún ayudante multimedia. Para eso los contenedores son estupendos.
Un comentarista lo explicó con claridad. Si sacas los servicios de una única VM gigante de Docker y los repartes en LXC separados, obtienes control a nivel de Proxmox sobre cada servicio. Si uno se rompe, restauras ese contenedor. Si uno necesita montar el almacenamiento de otra forma, te ocupas solo de ese. Si uno necesita un snapshot antes de actualizarse, no tienes que hacer un snapshot de un montón de aplicaciones que no tienen nada que ver. Esa granularidad es todo el atractivo, y una colección de LXC pequeños puede parecer un cajón ordenado en lugar de una caja de trastos con la etiqueta "Docker".
Lo mismo que hace eficientes a los LXC también pone nerviosa a la gente. Comparten el kernel del host y dependen de los namespaces y del aislamiento de contenedores en lugar de un sistema operativo invitado totalmente separado, así que un fallo del kernel lo bastante grave puede pesar más que dentro de una VM. Algunos usuarios citaron CVE recientes de Linux y conversaciones sobre fugas de contenedores como motivos para considerar la VM la opción más segura para servicios expuestos. Otros replicaron que el viejo lema de "las VM son más seguras" es un argumento caducado de antes de que los contenedores sin privilegios se volvieran lo normal.
Los dos bandos tienen parte de razón. Los LXC no son juguetes, y tampoco son VM. Fingir lo contrario en cualquiera de las dos direcciones es como la gente acaba tomando malas decisiones de diseño con total seguridad.
Las VM pesan más, pero a cambio te dan un muro
El mejor argumento a favor de las VM sigue siendo el aislamiento. Una VM ejecuta un sistema operativo aparte con su propio kernel. Eso no la hace invencible, pero te da una frontera más dura. Si alojas algo expuesto al público, que recibe tráfico real de desconocidos, o ejecutas software en el que no confías del todo, ese muro extra puede compensar el coste. Un comentarista lo resumió así: cualquier cosa que espere tráfico público real probablemente debería ir en una VM y bien cerrada.
Aun así, no todo servicio web público tiene que vivir en una VM. Algunos usuarios defendieron que los proxies inversos, la autenticación delegada (forward auth), proveedores de identidad como Authentik, OIDC, VPN como Netbird y herramientas como CrowdSec pueden reducir el riesgo práctico. Es el bando de la seguridad por capas: no expongas nada directamente si no hace falta, pon autenticación delante, limita el acceso y mantén pequeño el radio de impacto. Para un homelab en el que solo usan el servicio la familia o los amigos, eso puede bastar. Si el servicio es de verdad público, sobre todo si es desordenado o valioso, una VM deja de parecer paranoia y empieza a parecer un seguro barato.
Las VM también ganan cuando el software espera ser una máquina completa. Home Assistant OS es el ejemplo evidente del hilo; la gente suele ejecutarlo como su propia VM tipo appliance porque ese camino es sencillo, tiene soporte y da menos problemas. Los sistemas operativos de NAS son otro caso, sobre todo cuando se hace passthrough de controladoras HBA. Una VM también es el sitio natural para grandes pilas centralizadas de Docker Compose, si lo que buscas es gestionar las aplicaciones a la manera de Docker en lugar de traducir cada servicio a un LXC aparte.
Hay un precio, claro. Las VM consumen más CPU, RAM y almacenamiento, pueden tardar más en arrancar y pueden complicar el intercambio de archivos. También pueden restar visibilidad, porque Proxmox ve la VM pero no cada aplicación que hay dentro. Eso no siempre es malo, porque a veces quieres una "VM multimedia" o una "VM de herramientas de red". Aun así, es otro estilo de gestión: eliges una caja más robusta en lugar de un cajón más ligero.
Docker en una VM, Docker en un LXC o nada de Docker
Con Docker la gente empieza a hablar sin escucharse. La configuración original tenía una VM con una aplicación propia en Docker, un patrón muy habitual. A muchos usuarios les gusta Docker dentro de una VM porque mantiene el mundo Docker contenido. Puedes hacer copia de seguridad de la VM entera, restaurarla completa y olvidarte de preguntas raras sobre contenedores anidados. Un comentarista contó que ejecuta los contenedores Docker en VM dedicadas por temas, como multimedia o herramientas de red, porque así consigue aislamiento y mantiene agrupado el ecosistema de aplicaciones.
Los partidarios de LXC miran eso y preguntan por qué envolver cada servicio en Docker dentro de una VM cuando Proxmox puede gestionar el servicio directamente como su propio contenedor. Para ellos Docker añade otra capa, otro problema de copias de seguridad y otro sitio donde el estado de la aplicación y el de la infraestructura se enredan. Si Jellyfin, Pi-hole, nginx, AdGuard o Navidrome funcionan bien en un LXC, el LXC te da copias de seguridad, snapshots, montajes y restauraciones más sencillos y nativos de Proxmox. Si Immich se rompe, restauras el contenedor de ayer y sigues con tu vida. Ese es el sueño.
Docker sí tiene una ventaja real: las actualizaciones y el despliegue de aplicaciones pueden ser más fáciles. Los archivos Compose son portables, populares y están bien documentados, y muchos proyectos autoalojados publican primero las instrucciones para Docker. Hay usuarios que no quieren traducir cada aplicación al mundo LXC y prefieren mantener una VM de Docker y gestionar las aplicaciones como espera el proyecto original. Es razonable.
Así que Docker en una VM no está mal, y los LXC no siempre son más limpios. La decisión se reduce a quién quieres que gestione la frontera de la aplicación. Docker Compose es estupendo si te gustan las pilas de aplicaciones como código. Los LXC de Proxmox son estupendos si quieres que cada servicio sea una unidad de primera clase en el hipervisor. Una VM es estupenda cuando quieres levantar un muro alrededor de toda la pila y dejar de pensar en rarezas a nivel del host.
La discusión de seguridad se calentó porque todos tenían algo de razón
El hilo dio el giro brusco de siempre hacia el absolutismo en seguridad. Un comentarista dijo que la ventaja de una VM va más allá de un "mayor aislamiento": una VM es un entorno realmente virtualizado, mientras que un LXC es un entorno en contenedor que se ejecuta como un proceso en el host, más cerca de una separación al estilo chroot. Otro sostuvo que los contenedores modernos sin privilegios hacen que el viejo miedo parezca anticuado. Después llegó el debate sobre AppArmor y los exploits del kernel, con gente discutiendo si ciertas vías de fuga de contenedores estaban bloqueadas, se podían sortear, estaban corregidas o solo importaban en condiciones concretas.
Aquí es donde al principiante se le derrite el cerebro, y no es para menos. La respuesta práctica es más sencilla que la discusión. Una VM es la frontera de aislamiento más fuerte, y un LXC sin privilegios suele bastar para servicios normales de homelab que no están expuestos directamente a internet. Los LXC no están tan aislados como las VM, y usarlos tampoco es una imprudencia.
El error mayor es tratar "seguro" como un interruptor único. Un servicio público en una VM mal mantenida, con contraseñas débiles y puertos abiertos, puede seguir siendo un desastre. Un LXC privado detrás de una VPN y de forward auth, actualizado y con copia de seguridad, puede ser una opción perfectamente razonable para un homelab. El aislamiento importa, y también la exposición, los parches, la autenticación, el diseño de red, las copias de seguridad y lo doloroso que resulte recuperarse cuando algo se rompe.
El consejo más útil fue clasificar el riesgo en lugar de entrar en pánico con los LXC. Para una carga de trabajo expuesta al público, poco fiable, valiosa o empresarial, plantéate una VM. Para un servicio privado, una aplicación ligera con usuarios de confianza y una restauración sencilla, un LXC probablemente vale. Es el término medio aburrido, y es donde se toman la mayoría de las buenas decisiones de infraestructura.
La regla limpia: usa LXC hasta que una VM te aporte algo real
Para alguien que intenta ordenar su cabeza y su host de Proxmox, el hilo dejó un punto de partida sensato. Usa LXC para servicios Linux ligeros, sobre todo cosas como Pi-hole, AdGuard, nginx, servicios multimedia sencillos, herramientas de monitoreo y aplicaciones en las que quieres arranque rápido, poca sobrecarga, montajes directos de almacenamiento y copias de seguridad nativas de Proxmox fáciles. Usa una VM cuando el software viene empaquetado como appliance, cuando necesitas un sistema operativo aparte, cuando ejecutas Home Assistant OS, cuando quieres un gran mundo de Docker Compose, cuando haces passthrough de hardware de una forma que espera una máquina real o cuando el aislamiento es precisamente lo que buscas.
La mayoría de esos servicios LXC ligeros, entre ellos Pi-hole, AdGuard y decenas más, ya tienen despliegues de una línea en la colección Proxmox VE Helper Scripts, lo que te ahorra construir cada contenedor a mano.
Eso también significa que la configuración original no estaba mal. Home Assistant en una VM tiene sentido. Una aplicación Docker personal en una VM tiene sentido si Docker es el modelo de despliegue. Jellyfin, Pi-hole, nginx y servicios parecidos en LXC también tienen sentido. No hace falta abandonar los LXC; basta con dejar de esperar que un único tipo de contenedor resuelva todas las cargas de trabajo.
Hay además un aspecto de recuperación que a los principiantes a veces se les escapa. Si cada aplicación tiene su propio LXC, una aplicación rota no tiene por qué arrastrar a las demás, las copias de seguridad pueden ser más pequeñas y específicas, y las restauraciones más quirúrgicas. Una VM gigante llena de contenedores Docker puede ser más sencilla de actualizar, pero si el sistema de archivos de la VM o el estado de Docker se ensucian, puede que acabes restaurando un edificio entero porque reventó un fregadero. Ningún modelo es perfecto, así que elige el tipo de fallo que prefieras depurar.
Los usuarios más sensatos del hilo no intentaban ganar un concurso de pureza. Mezclaban las dos cosas, que es la verdadera manera Proxmox: VM para los muros, LXC para la velocidad y la granularidad, Docker donde Docker facilita la vida y copias de seguridad en PBS por todas partes, sin vergüenza ni ideología asociada a nada de ello.
La arquitectura gana a la superstición
El miedo a que una actualización del host rompa los LXC no es imaginario. Los contenedores comparten el kernel del host, así que los cambios en el host importan. Eso no hace malos a los LXC; significa que conviene actualizar con cuidado, hacer bien las copias de seguridad y evitar poner todos los servicios críticos en un único sitio frágil. Las VM son más autónomas, pero cuestan recursos y añaden trabajo de gestión, y no te van a salvar de una mala arquitectura, de malas copias de seguridad ni de una mala exposición.
La discusión dejó claro que los principiantes en Proxmox necesitan un marco de decisión más que definiciones. Pregúntate qué es el servicio, cuánto está expuesto, cuánto confías en él, cómo quiere instalarse, cuánto dolería restaurarlo, qué almacenamiento necesita, si necesita acceso al hardware y si te importa más el aislamiento o la granularidad. Normalmente la respuesta sale sola.
En un homelab, el punto de partida práctico es de una sencillez que se agradece: LXC para la mayoría de los servicios pequeños y de confianza, y VM para Home Assistant OS, pilas con mucho Docker, cargas de trabajo expuestas al público, sistemas tipo appliance y todo aquello en lo que un muro más fuerte compense el peso extra. Comparado con "todo en VM", ese reparto es un modelo mental mejor.
Lo mejor de Proxmox es que no te impone una única respuesta. Te deja construir el híbrido aburrido y sensato que encaja con tu vida. Tu Pi-hole no necesita un castillo, aunque tu aplicación pública quizá sí. Puede que tu Home Assistant quiera ser su propio pequeño appliance, y que tus herramientas multimedia estén más a gusto como contenedores con puntos de montaje limpios y copias de seguridad fáciles. Una mezcla así puede parecer desordenada, pero es el aspecto que tiene una arquitectura adulta.