En los homelabs basados en Proxmox hay una pregunta que vuelve una y otra vez: ¿tiene sentido ejecutar Docker dentro de un contenedor LXC o es más seguro hacerlo en una máquina virtual (VM)? Sobre el papel, la respuesta parecería obvia. Los LXC son más ligeros, arrancan antes y consumen menos recursos que una VM; la eficiencia es su carta de presentación. Pero tras esa ligereza hay matices técnicos y experiencias de campo que obligan a levantar el pie del acelerador: caídas del host por kernel panics, contenedores que no arrancan bajo ciertas políticas de seguridad, atajos de configuración que abren superficie de ataque o quebraderos de cabeza con NFS, GPU o passthrough de USB.
Lejos de ser un debate teórico, la discusión se ha ido escribiendo con horas de laboratorio y producción doméstica. Usuarios que han desplegado servicios en Docker dentro de LXC cuentan qué les funciona, qué fracasa y qué habrían querido saber antes de apostar la estabilidad del nodo a “contenedores dentro de contenedores”. El resultado no es un veredicto blanco o negro; es un mapa de riesgos, dependencias y prioridades.
Por qué seduce LXC: velocidad, simplicidad y control fino
La agilidad de LXC en Proxmox es difícil de ignorar. Un contenedor estándar arranca en segundos, consume menos memoria que una VM equivalente y permite asignar CPU/RAM con precisión quirúrgica. En ese contexto, encajar Docker dentro de LXC tiene lógica para quien ya domina compose y quiere empaquetar servicios sin cargar con el “peso” de una VM. Para algunos, la organización mental es incluso más clara: un LXC por servicio, o uno dedicado a un grupo de servicios de bajo impacto. Hay casos que escalan esta filosofía con decenas de LXC conviviendo con una o dos VMs de apoyo; gestionarlo es viable si se automatizan tareas rutinarias.
La familiaridad juega a favor: si el flujo es “clonar LXC base → desplegar compose → publicar puerto”, la curva de fricción es mínima. Y en servidores modestos —muy comunes en homelabs— exprimir recursos es un objetivo legítimo.
Cuando muerde: compartir el kernel no es gratis
El punto crítico es que LXC comparte el kernel del host. A diferencia de una VM, que aísla su propio kernel, un fallo severo dentro de un LXC puede propagarse al sistema anfitrión. Hay testimonios de procesos dentro del LXC con Docker que han disparado kernel panics y tumbado el nodo Proxmox completo; en una VM, el desastre habría quedado confinado a esa VM.
A ello se suma la doble superficie de riesgo: LXC tiene sus propias consideraciones de seguridad y Docker también. Apilarlos sin blindaje multiplica vectores potenciales de ataque o de fuga de privilegios. Y no todo contenedor Docker “de Internet” coopera con LXC: algunos servicios chocan con AppArmor, seccomp o cgroups, o exigen capacidades que un LXC no privilegioso no concede. El resultado práctico puede ser desde “arranca pero sin funcionalidad clave” hasta “no arranca”.
Los montajes de NFS, el passthrough de GPU o dispositivos USB y ciertas operaciones de red son otra zona gris. Muchas de estas tareas “sencillas en VM” se vuelven “quirks” en LXC que se resuelven a base de excepciones y overrides… cuando se resuelven.
Privilegiado vs. no privilegioso: el dilema de siempre
Buena parte de la discusión aterriza en una decisión privileged vs. unprivileged:
- LXC privilegiado. Es más “cercano” al host; Docker suele ir más cómodo, especialmente si hay GPU o USB. A cambio, aumenta el riesgo: si algo se desmadra, el salto al anfitrión es menos improbable.
- LXC no privilegioso. Aísla mejor y reduce impacto de errores. Pero Docker no siempre fluye: hay contenedores que piden capacidades o dispositivos que un entorno sin privilegios no expondrá sin trabajo extra.
Como alternativa, algunos han optado por Podman en modo rootless dentro de LXC no privilegioso. Es una combinación que reduce superficie y evita daemon con privilegios, pero no es bala de plata: no todo lo que se quiere ejecutar acepta ese modelo.
El término medio se impone: híbridos con criterio
A medida que la comunidad madura, los enfoques híbridos ganan peso. En esencia: VM para lo core o complejo, LXC para lo ligero.
- Quien valora aislamiento fuerte, GPU y compatibilidad universal, reserva una VM para Docker y su stack “gordo” (p. ej., Frigate, Immich, workloads de IA, pipelines de medios). La VM absorbe la complejidad y evita los tropezones de permisos.
- Quien prioriza eficiencia y un homelab sin exposición directa, despliega Docker dentro de LXC para servicios menores —DNS, métricas, utilidades internas— y acepta el peaje: si cae, no pasa nada irreparable.
- También hay quien elige cero Docker en LXC para servicios críticos y Docker sólo en VM, quedando LXC para instalaciones nativas (sin Docker) que juegan bien con el modelo de contenedor del kernel.
El denominador común es la segmentación del riesgo: aquello que no debe caerse ni contaminar el host vive en VM; lo que aporta comodidad y está bien si falla puede vivir en LXC con Docker.
Argumentos a favor de VM: estabilidad, seguridad y continuidad
El aislamiento de una VM no es solo un concepto: cada VM tiene su kernel. Si un contenedor o el daemon Docker se descompone, se cae la VM, no el host. A efectos operativos, eso significa ventanas de mantenimiento más seguras, actualizaciones de Proxmox menos delicadas y recuperaciones más limpias (restaurar la VM o tirar de snapshot).
Un punto práctico poco comentado es la eficiencia de copias de seguridad. En Proxmox, las VMs disponen de “dirty bitmaps” que permiten incrementales reales; en LXC, el escaneo completo de volúmenes en cada ciclo puede alargar ventanas y cargar el backend de almacenamiento. En homelabs con discos modestos, los backups de VM suelen ser más predecibles.
La compatibilidad con contenedores “difíciles” (por permisos, capacidades o acceso a hardware) también suele ser superior en VM: menos workarounds, menos excepciones en el AppArmor profile, y GPU/Nvidia drivers que siguen guías bien conocidas.
¿Cuándo sí tiene sentido Docker en LXC?
No todo son señales de “prohibido”: hay escenarios donde Docker en LXC funciona bien y aporta valor:
- Servicios internos no críticos (monitorización, DNS secundario, automatizaciones caseras) en LXC no privilegioso, con compose sencillo y sin bind mounts exóticos.
- Homelabs de bajo consumo donde una VM adicional rompe el presupuesto de RAM o CPU; a condición de asumir el plan de contingencia (copias fuera del host, snapshots frecuentes, pruebas tras cada actualización de kernel).
- Entornos de aprendizaje en los que se busca practicar con Linux, cgroups, AppArmor, namespaces y seguridad a bajo nivel. El valor didáctico existe, siempre que el riesgo esté acotado (sin exposición directa a Internet, sin datos sensibles).
Guía de decisión: tres preguntas que zanjan el debate
- ¿Qué pasa si se cae? Si la respuesta es “nada grave, lo levanto luego”, LXC es candidato. Si es “impacto al hogar/oficina/cliente”, vaya a VM.
- ¿Necesita GPU, NFS o dispositivos especiales? Si la respuesta es sí, VM simplifica la vida. Si no, LXC puede valer (mejor no privilegioso).
- ¿Hay exposición pública o datos sensibles? Con Internet de por medio, aislamiento fuerte siempre suma. La VM ayuda a dormir mejor.
Buenas prácticas si se insiste con LXC
- No privilegios por defecto. Empiece por LXC no privilegioso; suba privilegios solo si hay justificación clara.
- Endurezca Docker. Evite
--privileged, limiteCAP_ADD, use perfiles AppArmor/seccomp y no monte/var/run/docker.socka contenedores a la ligera. - Montajes con cabeza. Prefiera bind mounts de solo lectura donde tenga sentido; documente cada excepción.
- Rootless cuando proceda. Podman rootless dentro de LXC no privilegioso reduce superficie; valide compatibilidades antes de migrar.
- Backups fuera del host. Copias remotas, versionadas y probadas (restauraciones reales) valen más que la promesa del snapshot rápido.
- Pruebe tras cada kernel. Los LXC comparten kernel; pruebas tras actualizaciones de Proxmox son obligatorias.
- Cuide la observabilidad. Registre eventos de Docker y del LXC; al primer síntoma de inestabilidad (bloqueos, soft lockups), migra a VM ese servicio.
Rendimiento y eficiencia: cuánto “cuesta” la VM
El sobrecoste de una VM moderna en Proxmox suele ser modesto para cargas típicas de homelab (servicios web, bases de datos ligeras, apps en Go/Node/Python). Para IA con GPU, vídeo o pipelines intensivos, la diferencia de rendimiento viene más por acceso a hardware y topología de red/almacenamiento que por la propia virtualización. Donde la VM gana por goleada es en gestión de riesgos: aislar kernel, encapsular dependencias, acotar el radio de explosión y simplificar restore/rollback.
Casos de uso reales: cinco patrones que se repiten
- VM con Docker y GPU para cargas de IA; el resto en LXCs nativos. Modular, claro y fácil de mantener.
- Once LXC, uno por servicio en servidor de bajo consumo. Cada uno hace una cosa; administración por automatización.
- Un LXC “comodín” con todos los Docker menores. Gestión simple sin migrar cada app a instalación nativa LXC.
- Docker en LXC solo para lo no crítico y VM para cualquier servicio que importe.
- Kubernetes sobre VM para quien busca orquestación y escalabilidad “de verdad”, dejando a un lado Docker en LXC.
Conclusión: no es una bomba… pero el cableado importa
La pregunta “¿Docker en LXC es una bomba de relojería?” admite una respuesta honesta: no, si se asume la ingeniería y el riesgo. Es más parecido a una partida de Jenga: se puede construir algo alto, eficiente y elegante, pero un bloque mal retirado (un kernel inadecuado, un contenedor mal dimensionado, un permiso de más) puede llevarse por delante más de lo que se pensaba.
Para servicios internos y labs de aprendizaje, Docker en LXC puede funcionar sin dramas si se aplican buenas prácticas y se mantiene un plan de recuperación. Para servicios expuestos, con autenticación, acceso a medios, modelos de IA o APIs públicas, la VM suele merecer su sobrecoste: aislamiento, copias más eficientes, compatibilidad y tranquilidad.
La decisión, al final, no va de dogmas sino de amenazas y prioridades. Se trata de elegir qué riesgos aceptar y dónde; de repartir cargas entre VM y LXC con la cabeza fría; y de recordar que un homelab no es una medalla por evitar VMs, sino un espacio para aprender, iterar y mejorar.
Preguntas frecuentes
¿Es seguro ejecutar Docker dentro de un LXC en Proxmox para un servidor doméstico?
Puede ser razonablemente seguro para servicios internos y no críticos si se usa LXC no privilegioso, se endurecen políticas (AppArmor, seccomp, capacidades mínimas) y se cuenta con copias de seguridad externas. Para servicios expuestos a Internet o con datos sensibles, la VM aporta aislamiento y reduce el impacto de errores.
¿Cuándo conviene usar una máquina virtual para Docker en Proxmox?
Cuando el servicio es crítico, requiere GPU/NFS/passthrough sin fricciones, o se necesita compatibilidad total con contenedores “exigentes”. La VM aísla el kernel, facilita backups incrementales y evita que un fallo tumbe el host.
¿Qué problemas habituales aparecen con Docker en LXC (y cómo mitigarlos)?
Conflictos con AppArmor/seccomp, contenedores que piden capacidades extra, líos con NFS o GPU, y, en casos extremos, inestabilidad del host por compartir kernel. Mitigue con LXC no privilegioso, perfiles ajustados, Podman rootless donde sea posible y migración a VM si el servicio es sensible.
¿Es mejor “un LXC por servicio” o “una VM con todos los Docker”?
Depende de prioridades. Un LXC por servicio simplifica aislar fallos y recursos, pero multiplica piezas. Una VM con el stack Docker concentra gestión, brinda aislamiento fuerte y suele facilitar backups. En la práctica, muchos optan por modelo híbrido: VM para lo importante, LXC para lo ligero.
Fuentes:
— Mr.PlanB, «Is Docker in LXC a Ticking Time Bomb? What Proxmox Users Have Learned», mrplanb.com.
