VM o contenedor LXC en Proxmox: cuándo usar cada uno
Antes de crear cualquier servicio en Proxmox me hago siempre las mismas preguntas. Este es el árbol de decisión que uso, con los casos concretos donde cada opción tiene sentido.
Si instalaste Proxmox, ya conoces esta duda
Tienes el panel abierto, un servicio nuevo que quieres levantar, y el cursor parado entre «Crear CT» y «Crear VM». Sabes que no es lo mismo, pero en ese momento tampoco tienes claro cuál es la opción correcta para este caso concreto. Llevas ahí más tiempo del que te gustaría reconocer.
No es que seas principiante. Tienes servicios corriendo, quizás snapshots programadas, puede que hasta un clúster de dos nodos. Pero la decisión entre contenedor LXC y máquina virtual sigue sintiéndose un poco arbitraria cada vez. A veces copias lo que hiciste la última vez. A veces preguntas en el foro. A veces simplemente tiras a cara o cruz.
Este post te va a resolver eso de forma práctica. Te explico el árbol de cuatro preguntas que me hago yo antes de crear cualquier servicio en Proxmox: los criterios reales, con los casos donde cada tipo gana sin discusión y los casos donde la respuesta no es tan evidente. La próxima vez que abras ese menú, sabrás exactamente qué elegir y por qué.
Por qué importa
Aislamiento real importa
Un LXC privilegiado comparte uid 0 con el host; una VM tiene su propio kernel aislado. Para servicios expuestos a internet, VM sin dudarlo.
RAM desde el primer segundo
Un contenedor Alpine arranca en menos de 1 s y consume ~5 MB; una VM Debian mínima parte de ~200 MB solo por el kernel guest.
Kernel propio o compartido
LXC no puede correr un kernel distinto al del host. Si necesitas Windows, un kernel personalizado o módulos específicos, solo una VM lo resuelve.
GPU y migración en vivo
El passthrough VFIO y la live migration son nativos en KVM. En LXC requieren configuración manual con limitaciones según el driver.
El kernel lo es todo
Cuando arrancas un contenedor LXC en Proxmox, no estás arrancando un sistema operativo completo. Estás arrancando un proceso —o un conjunto de procesos— que comparte el kernel del host. Nada más, nada menos. Eso explica por qué un Alpine vacío parte de unos 5 MB de RAM y está listo en menos de un segundo.
Una VM KVM es otra historia: QEMU levanta un kernel guest completo sobre la capa de virtualización hardware. Eso cuesta memoria, tiempo de arranque y algo de CPU. A cambio tienes aislamiento total: el guest no sabe que hay un host debajo, y el host no puede ver dentro del guest salvo por los canales que tú abras.
Esa diferencia —kernel compartido frente a kernel propio— es el eje de todas las decisiones que vienen después.
El árbol de preguntas que uso antes de crear cualquier servicio
No hay regla universal. Lo que sí hay es un orden de preguntas que me ahorra la mayoría de los errores.
¿Necesitas correr algo que no sea Linux?
Windows, FreeBSD, un kernel personalizado, cualquier OS distinto al del host: VM sin discusión. LXC no puede ejecutar un kernel diferente al del host. Si el host corre Linux 6.8, todos tus contenedores corren sobre ese mismo 6.8. No hay vuelta de hoja.
¿El servicio necesita acceso directo al hardware?
GPU passthrough con VFIO es nativo en KVM. Funciona bien, es el camino documentado y hay miles de guías. En LXC también puedes pasar dispositivos, pero la configuración es manual, depende del driver, y las garantías cambian según la tarjeta. Si el servicio requiere GPU de verdad —Jellyfin con transcoding hardware, Stable Diffusion local, un escritorio con gráficos— yo voy a KVM directamente.
Para pasar un disco USB o un dispositivo de almacenamiento concreto, LXC puede ser suficiente según el caso.
¿Qué nivel de aislamiento necesitas?
Aquí hay que ser honesto. Proxmox ofrece dos modos de LXC:
- Privilegiado: el UID 0 dentro del contenedor es el UID 0 real del host. Tiene acceso directo a
/dev. Si algo dentro del contenedor consigue salir, está en el host. - No privilegiado: el UID 0 dentro se mapea a un UID alto en el host (por ejemplo, 100000). El aislamiento mejora considerablemente, aunque no es equivalente al de una VM.
Para servicios propios, en una red interna, con código que conoces: LXC no privilegiado es perfectamente razonable. Para workloads de terceros, servicios expuestos directamente a internet o código que no controlas al cien por cien: VM, o al menos mencionar en voz alta el riesgo de escape de contenedor antes de seguir adelante.
¿Cuánto te importa el overhead de recursos?
Una VM Debian mínima parte de unos 200 MB de RAM solo por el kernel guest y los servicios base. Un contenedor LXC con el mismo servicio parte de lo que consuma ese servicio. Si tienes un servidor con 32 GB y cuatro VMs, eso es tolerable. Si tienes un mini-PC con 8 GB y quieres correr quince servicios de homelab, la diferencia empieza a importar de verdad.
Cuándo voy a LXC sin pensarlo dos veces
La mayoría de mis servicios de homelab viven en contenedores LXC no privilegiados. Son rápidos de crear, consumen pocos recursos y se administran como cualquier sistema Linux.
- Pi-hole o AdGuard Home: Alpine o Debian ligero, sin necesidades especiales de kernel.
- Nginx como reverse proxy: puro software, sin hardware especial.
- Bases de datos internas (PostgreSQL, MariaDB) que solo hablan con otros servicios propios.
- Gitea, Vaultwarden, Nextcloud sin transcoding de vídeo.
- Cualquier cosa que pueda morir y levantarse en diez segundos sin drama.
Ejemplo concreto: tengo un LXC Alpine corriendo Pi-hole que arranca en menos de un segundo, usa unos 30 MB de RAM en reposo y lleva tres años sin que le haya prestado atención. Para eso no necesito una VM.
Cuándo voy directamente a VM
Hay servicios donde la VM no es un lujo, es la única opción razonable:
- Windows: para trabajo, gaming o software que solo existe en Windows. KVM con drivers VirtIO funciona muy bien.
- GPU passthrough: Stable Diffusion, Jellyfin con NVENC, o cualquier workload que necesite la GPU de verdad.
- Kernels personalizados: si necesitas compilar el kernel con opciones específicas o testear algo sin afectar al host.
- Aislamiento estricto: servicios expuestos a internet con código que no controlo al completo. El overhead de la VM me compensa.
- Testing de distribuciones: para probar una distro nueva o un instalador, una VM es lo natural.
El día que instalé Proxmox en mi servidor principal, lo primero que creé fue una VM Windows 11 para el trabajo. El passthrough de USB para teclado y ratón requiere algo de configuración inicial, pero una vez asentado, la diferencia de rendimiento respecto a hardware bare metal es mínima para tareas de oficina.
Docker dentro de LXC: funciona, con matices
Una pregunta que aparece constantemente: ¿puedo correr Docker dentro de un contenedor LXC? La respuesta es sí, pero con configuración específica.
En Proxmox hay que habilitar las opciones nesting y keyctl en la configuración del contenedor. Con eso, Docker funciona dentro de un LXC no privilegiado. Yo lo uso así para algunos stacks de Compose que no justifican una VM entera.
Dicho esto, hay situaciones donde prefiero una VM para Docker:
- Cuando el stack incluye contenedores que necesitan capacidades de kernel elevadas (
CAP_SYS_ADMINy similares). - Cuando quiero que el entorno Docker sea completamente independiente del host y reproducible.
- Cuando estoy probando algo nuevo y no quiero sorpresas en el kernel compartido.
El Docker-dentro-de-LXC funciona bien para casos simples; para casos complejos, una VM Debian con Docker instalado da menos dolores de cabeza. No hay una respuesta única.
Snapshots y migraciones: lo que cambia en la práctica
Tanto VMs como contenedores LXC soportan snapshots en Proxmox, pero hay diferencias que importan cuando algo falla.
Snapshots consistentes
Las VMs con el agente QEMU instalado permiten hacer quiescing del guest antes de la snapshot: el sistema operativo guest congela escrituras a disco, se toma la imagen y se reanuda. El resultado es una snapshot consistente a nivel de aplicación. En LXC la snapshot congela el estado del contenedor, pero sin un mecanismo de quiescing equivalente; si hay escrituras en curso, la consistencia depende de cómo gestione las interrupciones el servicio en cuestión.
Para bases de datos críticas prefiero VM con agente QEMU. Para servicios sin estado o con datos fácilmente regenerables, LXC funciona bien.
Migración en vivo
La live migration de VMs KVM en Proxmox funciona entre nodos del mismo cluster con o sin almacenamiento compartido. En LXC, la migración en vivo solo funciona con almacenamiento compartido. Si tus nodos tienen almacenamiento local, migrar un LXC implica un tiempo de parada.
Para la mayoría de homelabs con un solo nodo Proxmox esto no importa. Si tienes un cluster o piensas en alta disponibilidad, es un factor a considerar antes de decidir cómo desplegar un servicio crítico.
Preguntas frecuentes
Q: ¿Cuándo merece la pena usar una VM en vez de LXC?
A: Cuando el servicio necesita su propio kernel, drivers específicos, o vas a exponer el servicio directamente a internet. También si necesitas correr Windows o cualquier OS no-Linux: un contenedor LXC no puede ejecutar un kernel diferente al del host, así que ahí no hay debate.
Q: ¿Qué pasa si quiero correr Docker dentro de un LXC?
A: Se puede, pero requiere activar 'nesting' y 'keyctl' en las opciones del contenedor en Proxmox, y el contenedor debe ser no privilegiado para mantener un mínimo de aislamiento. Funciona bien para uso doméstico; para cargas críticas o de terceros, una VM es más segura.
Q: ¿Cuánto RAM mínima consume un LXC frente a una VM?
A: Un contenedor LXC Alpine vacío arranca en Proxmox consumiendo unos 5 MB de RAM; una VM Debian mínima parte de unos 200 MB solo por el kernel guest y QEMU. Si el servidor tiene memoria justa y corres muchos servicios ligeros, la diferencia acumula.
Q: ¿Vale LXC privilegiado para un servicio expuesto a internet?
A: Con cautela. Un LXC privilegiado mapea el uid 0 del contenedor al uid 0 real del host, lo que reduce significativamente el aislamiento. Si el servicio tiene vulnerabilidades y alguien escapa del contenedor, tiene root en el host. Para exposición pública, usa LXC no privilegiado o directamente una VM.
Q: ¿Cómo afecta la elección a las snapshots y migraciones?
A: Las snapshots funcionan en ambos, pero las VMs permiten quiescing del guest mediante el agente QEMU para snapshots consistentes con la app corriendo. La migración en vivo solo está soportada de forma nativa en VMs KVM; en LXC requiere almacenamiento compartido entre nodos y tiene más limitaciones.
Deja una respuesta