Hay una discusión que aparece cada poco en cualquier grupo de Proxmox. LXC o VM. Como si hubiera que casarse con una sola cosa y defenderla hasta el final de los tiempos. Yo hace tiempo que me bajé de esa pelea porque en la práctica no me sirve para nada. En mi homelab uso las dos. Y cuanto más tiempo llevo con Proxmox, más claro tengo que la decisión buena no sale de una religión técnica. Sale de saber qué servicio tienes delante y cuánto castigo te puede devolver si eliges mal.
Los LXC me encantan cuando quiero algo ligero, rápido y razonablemente simple. Arrancan antes, gastan menos y te permiten tener servicios pequeños muy ordenados sin pagar el peaje de una máquina completa. Las VMs me siguen pareciendo la opción correcta cuando necesito aislamiento serio, otro sistema operativo, un kernel propio o simplemente paz mental. Porque sí, a veces la paz mental consume más RAM. Y aun así sale rentable.
La documentación de Proxmox lo explica bastante bien. Los contenedores usan el kernel del host y por eso tienen un coste muy bajo. También dejan clara la contrapartida, que no puedes correr cualquier cosa ahí dentro como si fuera una máquina independiente. Solo Linux, menos libertad a bajo nivel y algunas limitaciones que no molestan hasta que justo molestan. Con las VMs pasa lo contrario. Pagas más recursos, pero ganas compatibilidad, aislamiento y menos sorpresas raras.
Yo no tomo esta decisión con teoría abstracta. La tomo mirando mi propio lab. Qué servicios toco más, cuáles reinicio sin drama, cuáles quiero romper sin miedo y cuáles prefiero mantener encerrados en una caja más gruesa. Esa es la parte útil.
el error está en buscar un ganador#
Si alguien me pide una regla universal, no la tengo. Y casi mejor.
Buscar un ganador absoluto entre LXC y VM en Proxmox es como intentar decidir si siempre conviene más un destornillador o un taladro. Depende del trabajo. El problema es que en homelab nos encanta convertir una decisión práctica en una identidad. El resultado suele ser bastante cutre. O llenas el nodo de VMs para servicios minúsculos porque te da respeto tocar LXC, o metes cosas demasiado delicadas en contenedores solo para presumir de eficiencia.
Yo ya he pasado por las dos torpezas. Primero me dio por simplificar demasiado y meter cualquier servicio pequeño en contenedor porque me parecía elegante. Después me fui al otro extremo con alguna VM que, vista con calma, era matar moscas a cañonazos. Ninguno de los dos extremos me hizo mejor admin. Solo me hizo perder tiempo.
Lo que me funciona ahora es más aburrido y bastante más efectivo. Cada servicio se gana su sitio según lo que pide de verdad. No según lo bonito que quede luego en una captura del panel.
qué cambia de verdad entre LXC y VM#
La diferencia importante no es visual. En Proxmox ambas viven bastante bien integradas y desde la interfaz parece que forman parte de la misma familia. Pero por debajo no juegan al mismo deporte.
LXC es contenedor de sistema. Comparte kernel con el host. Eso reduce el overhead muchísimo y hace que para muchos servicios Linux pequeños el resultado sea una maravilla. Arranca rápido, suele ir fino y te permite aprovechar mejor el hardware. Cuando el nodo no va sobrado, se nota.
Una VM en Proxmox usa QEMU y KVM. Ahí ya estás virtualizando una máquina completa. Tienes tu propio kernel invitado, tu propio stack más aislado y mucha más libertad a la hora de instalar cosas raras, tocar módulos, usar otros sistemas operativos o encapsular un stack complejo sin pensar tanto en las costuras del host.
Dicho en bruto, que a veces es como mejor se entiende.
- Si necesito ligereza y el servicio encaja bien en Linux compartiendo kernel, miro LXC primero.
- Si necesito aislamiento fuerte, compatibilidad amplia o cero ganas de pelearme con limitaciones sutiles, voy a VM.
Lo demás ya son matices.
cómo se ve eso en mi Proxmox ahora mismo#
Esta captura sale de uno de mis nodos y me gusta porque enseña algo que muchas comparativas pasan por alto. En la vida real no suelo elegir una sola vía. Mezclo ambas según la carga.
En ese momento tenía dos VMs en marcha y cuatro contenedores activos en el mismo entorno, con más contenedores preparados para servicios que no necesito tener siempre encendidos. Solo con esa foto ya se ve bastante bien mi criterio actual. Las VMs se quedan para cargas más pesadas o más delicadas. Los contenedores se llevan la parte ligera, de red o de utilidades que quiero tener bien colocadas sin malgastar recursos.
Esa mezcla me parece mucho más sana que intentar demostrar que una tecnología reemplaza por completo a la otra. No la reemplaza. La complementa.
dónde sí me compensa un LXC#
servicios pequeños y bastante aburridos#
Lo digo como halago. Los mejores candidatos para un LXC suelen ser justo los servicios aburridos. DNS local, algún nodo de Tailscale, herramientas de red, algún panel sencillo, algún watcher, un servicio que hace una cosa concreta y no necesita postureo. Ahí LXC brilla.
Me gusta porque el coste mental es bajo. Creo el contenedor, le doy recursos razonables, dejo la red en su sitio y sigo con mi vida. Si además el servicio va a vivir meses sin grandes cambios y no necesita cosas raras de kernel, mejor todavía.
En este tipo de servicios yo valoro tres cosas.
- Arranque rápido
- Menos RAM reservada
- Menos sensación de estar usando una excavadora para plantar una flor
Y sí, esa última también cuenta. Una VM entera para un servicio pequeño puede funcionar perfecto, pero a veces es una forma bastante cara de evitar pensar cinco minutos.
cosas que quiero levantar rápido#
Aquí también me resultan comodísimos. Cuando estoy probando una utilidad nueva, una pieza de red, una herramienta ligera o algo que probablemente voy a borrar en unos días, prefiero LXC casi siempre. El ciclo de vida es más ágil y me da menos pereza rehacer.
Eso cambia mucho cómo administro el lab. Si crear algo es barato, también es barato tirarlo y volver a empezar. Y eso mejora el orden bastante. No me aferro tanto a una instancia mediocre solo porque montarla otra vez sea una pesadilla.
cuando quiero gastar menos RAM sin jugar a la ruleta#
Ahorro de recursos sí, pero con cabeza. Aquí es donde LXC tiene una ventaja muy real. En nodos modestos o en servicios que no merecen 8 o 16 GB de memoria por puro protocolo, poder asignar contenedores más ligeros me deja encajar más piezas sin que el host vaya ahogado.
El matiz importante es el de “sin jugar a la ruleta”. Si para ahorrar 2 o 3 GB acabo creando un entorno más frágil o más difícil de mantener, el ahorro ya no compensa. El ahorro bueno es el que no me devuelve una factura en tiempo de troubleshooting.
dónde prefiero una VM aunque gaste más#
todo lo que necesita su propio kernel o sus rarezas#
Aquí no me complico. Si algo necesita otro sistema operativo, módulos concretos, un comportamiento muy particular del kernel o simplemente no quiero pasarme la tarde viendo qué syscall se enfada hoy, lo mando a una VM.
Los contenedores tienen límites muy razonables. El error es fingir que no los tienen. Si el servicio va a convivir mal con esas limitaciones, más vale asumirlo antes que intentar domesticarlo a base de parches raros.
stacks que toco mucho y no quiero romper por debajo#
Esto me pasa con servicios más sensibles o con cosas que sé que voy a trastear bastante. Docker dentro de VM me da más tranquilidad que Docker dentro de cualquier LXC montado deprisa y corriendo. Sí, se puede hacer en LXC. También se puede convertir una cocina en un taller. La pregunta no es si puedes. La pregunta es si te compensa.
Cuando voy a tocar mucho el stack, instalar cosas, probar upgrades, añadir servicios auxiliares o cambiar piezas con frecuencia, una VM me da un borde más claro. Lo que pase dentro se queda más dentro. Para mí eso vale recursos.
cualquier cosa que huela a experimento serio#
Hay experimentos pequeños y experimentos que se te pueden ir de las manos. Para los segundos prefiero una VM. Si voy a probar algo de IA local, un servicio nuevo con dependencias delicadas, una distribución distinta o un montaje que puede acabar tocando red, disco y automatizaciones, quiero más aislamiento. No porque vaya a explotar el nodo, sino porque duermo mejor si la caja es más gruesa.
la captura que mejor resume la diferencia#
Esta comparación sale de configuraciones reales saneadas y resume bastante bien por qué no trato igual a ambos tipos de carga.
La VM tiene más memoria, más disco y una configuración pensada para una carga más exigente. El LXC va mucho más contenido y además en modo no privilegiado, que es justo como me gusta dejar los contenedores siempre que puedo. No porque quede bonito decirlo, sino porque reduce superficie de desastre.
Lo importante aquí no es el número exacto de gigas. Es la intención. Cuando una carga nace como LXC, suele hacerlo porque quiero eficiencia y sencillez. Cuando nace como VM, suele ser porque quiero margen, compatibilidad o aislamiento. Ver las dos configuraciones una al lado de la otra ayuda a recordar que no estoy desplegando dos sabores de lo mismo.
errores que ya he pagado yo#
meter Docker dentro de cualquier LXC porque sí#
Este clásico me lo conozco. Hay casos donde funciona bien y gente muy contenta con ello. No digo que esté prohibido. Digo que no siempre merece la pena.
Si el objetivo es exprimir recursos y sabes lo que haces, adelante. Pero si lo haces por rutina, luego empiezan las notas mentales sobre nesting, privilegios, cgroups, permisos raros, storage, redes que se comportan distinto y ese precioso momento en que ya no recuerdas si el problema está en Docker, en el contenedor o en la capa de Proxmox. He perdido suficientes ratos ahí como para no venderlo como receta universal.
obsesionarme con ahorrar recursos aunque luego pierda tiempo#
Este es probablemente el error más habitual en homelab. Nos obsesionamos con lo ligero porque suena inteligente. Luego llega una tarde de depuración bastante fea y descubres que haber reservado algo más de RAM y meter el servicio en una VM te habría salido muchísimo más barato.
Yo ya no celebro un ahorro de recursos si viene acompañado de una arquitectura más delicada de la cuenta. El benchmark de verdad no es solo memoria usada. También es cuántas ganas te quedan de tocar ese servicio dentro de tres meses.
usar una VM para un servicio minúsculo por puro conservadurismo#
La torpeza contraria también existe. A veces por no complicarte, levantas una VM completa para algo que cabía perfectamente en LXC y no iba a pedir nada raro nunca. Si eso te pasa una vez, no pasa nada. Si te pasa veinte, conviertes el nodo en una colección bastante pesada de máquinas que están infrautilizadas todo el día.
Yo intento evitarlo porque luego esa inercia condiciona todo lo demás. Más disco asignado del que hace falta, más memoria desperdiciada, más mantenimiento por instancia y menos ganas de separar servicios pequeños porque cada uno parece costar demasiado.
mi regla rápida para decidir#
No es infalible, pero me sirve bastante.
Empiezo pensando en LXC si se cumplen estas condiciones.
- El servicio es Linux puro y bastante estándar
- No necesita kernel propio ni trucos raros
- Quiero eficiencia y arranque rápido
- Si mañana lo borro y lo recreo, no me cambia la vida
Empiezo pensando en VM si aparece cualquiera de estas.
- Necesito otro sistema operativo
- Espero pelearme con dependencias, módulos o capas delicadas
- Quiero aislar mejor un stack grande o conflictivo
- El servicio tiene suficiente importancia como para pagar el extra de recursos con gusto
No es una regla académica. Es una regla hecha a golpes, que suele ser la mejor clase de regla.
cuándo muevo algo de un LXC a una VM#
Esto también me parece importante. Elegir LXC primero no te obliga a defender esa decisión para siempre.
Yo muevo un servicio a VM cuando empiezo a notar una de estas señales.
- El contenedor necesita excepciones raras para seguir funcionando cómodo
- Empiezo a dudar de qué depende del host y qué depende del servicio
- Las actualizaciones me dan más miedo del razonable
- Ya no estoy ahorrando tiempo, solo RAM
En ese punto prefiero asumir que el servicio ha crecido o que mis necesidades cambiaron. Lo paso a VM y listo. No vivo ese cambio como una derrota de LXC. Lo vivo como una señal de que estaba intentando exprimir una herramienta fuera de su zona buena.
dónde encaja esto con el resto del homelab#
Esta decisión no vive aislada. También depende de cómo tengas montado el resto.
Si despliegas rápido con buenas plantillas, como contaba en Cloud-init en Proxmox: así preparo plantillas útiles y levanto VMs Linux en minutos, crear una VM ya no da tanta pereza. Si tienes el cluster ordenado y repartes cargas con cabeza, como conté en Cómo reparto las VMs en mi cluster Proxmox para no convertir un nodo en el pringado de la casa, las VMs dejan de parecer un lujo caro. Y si ya te peleaste con la topología del cluster, como en Proxmox cluster de 3 nodos en mini PCs: lo que haría distinto después de montarlo en casa, aprendes rápido que la pureza ideológica importa bastante menos que la operativa.
También conviene no mezclar este debate con el de Incus o LXD. Son conversaciones primas, no idénticas. Si te interesa esa vía, ya escribí sobre Incus: el fork de LXD que hace lo que Docker no puede. Aquí estoy hablando de cómo tomo la decisión dentro de Proxmox para cargas reales de mi casa.
mi conclusión#
Si tuviera que resumirlo en una sola frase, sería esta. LXC me gusta para lo pequeño y estable. VM me gusta para lo delicado, lo raro o lo que quiero tocar sin mirar de reojo al host.
No necesito un ganador absoluto porque mi homelab tampoco tiene un único tipo de problema. Tengo servicios aburridos que piden ligereza, piezas de red que merecen contenedor, cargas más serias que me piden VM y experimentos a los que prefiero poner una pared más gruesa alrededor. Proxmox me deja hacer esa mezcla con bastante dignidad. Lo tonto sería no aprovecharla.
Así que si estás dudando entre LXC y VM, mi consejo no es que copies un dogma. Mira el servicio, mira el riesgo, mira tus ganas reales de mantenerlo y elige la herramienta que te quite más fricción. No la que te haga sentir más listo en un hilo de Reddit.
Porque al final lo que más valoro en un homelab no es ahorrar 600 MB. Es no fabricar problemas elegantes que luego me explotan un domingo.
referencias#
- Proxmox Container Toolkit
- QEMU/KVM Virtual Machines en Proxmox VE
- Post relacionado: Cloud-init en Proxmox: así preparo plantillas útiles y levanto VMs Linux en minutos
- Post relacionado: Proxmox HA: alta disponibilidad para tus VMs sin infrastructure enterprise
- Post relacionado: Incus: el fork de LXD que hace lo que Docker no puede