LXC vs máquinas virtuales en Proxmox: cuándo usar cada uno

agosto 4, 2026 Alfonso Moreno | Sysadmin Senior 104 Visitas 11 min de lectura

Proxmox VE administra contenedores LXC y máquinas virtuales KVM desde el mismo panel, pero no son dos formatos equivalentes. Elegir bien depende del kernel, el aislamiento, la carga y la forma en que vas a mantener el servicio.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 4-6 horas para setup completo.
Requisitos: CPU con VT-x, 16+ GB RAM, 64+ GB SSD.
Resultado: Homelab con VMs/LXC, backups PBS, monitoring integrado.
Troubleshooting: Logs de Proxmox, snapshots, restore drills mensuales.

1. Dos modelos de virtualización diferentes

Una máquina virtual emula o presenta hardware virtual mediante QEMU y usa KVM para ejecutar código con asistencia del procesador. Cada VM inicia su propio firmware, cargador y kernel. El invitado se comporta como un equipo independiente, dentro de los límites configurados por el hipervisor.

Un contenedor LXC usa funciones del kernel Linux para aislar procesos. Namespaces separan vistas de recursos como procesos, red y montajes; cgroups controlan y contabilizan recursos. El contenedor tiene su propio espacio de usuario, pero comparte el kernel del host. Proxmox añade herramientas de gestión, plantillas, red, almacenamiento, backup y permisos sobre LXC.

La diferencia no es que LXC sea “una VM pequeña”. Son límites arquitectónicos distintos:

Aspecto	LXC	Máquina virtual KVM
Kernel	Compartido con el host	Propio por invitado
Sistemas invitados	Distribuciones Linux compatibles	Linux, Windows y otros compatibles
Arranque	Inicia procesos del contenedor	Arranca un sistema completo
Aislamiento	A nivel de kernel y procesos	Frontera de hardware virtual
Sobrecarga	Generalmente menor	Mayor por sistema completo
Flexibilidad	Condicionada por el kernel del host	Mayor control del SO invitado

Esta tabla no decide por ti. Un servicio pequeño puede requerir VM por seguridad, mientras una aplicación pesada puede encajar bien en LXC si confías en ella y acepta el kernel compartido.

2. Recursos, densidad y rendimiento sin mitos

LXC evita arrancar un kernel por invitado y suele necesitar menos memoria y almacenamiento base. Eso permite alojar más servicios pequeños en un homelab limitado. El inicio y apagado también suelen ser rápidos porque se administran grupos de procesos, no un equipo virtual completo.

Una VM reserva o gestiona memoria para un sistema operativo completo y mantiene dispositivos virtuales. Los controladores paravirtualizados VirtIO reducen el coste de entrada/salida, pero no eliminan el kernel ni los servicios del invitado. A cambio obtienes una frontera más clara y control completo sobre sus actualizaciones.

No hay un porcentaje universal de diferencia. Depende de CPU, almacenamiento, controlador virtual, caché, red, kernel, aplicación y patrón de acceso. Evita decidir a partir de un benchmark aislado publicado con otro hardware.

Pregunta de capacidad	Qué revisar
¿Falta RAM?	Consumo real del servicio y caché, no solo memoria asignada
¿El disco es el límite?	Latencia, IOPS, tipo de almacenamiento y patrón de escritura
¿La CPU se satura?	Límites, afinidad, tiempo de CPU y carga del host
¿Hay demasiados invitados?	Margen operativo, backups simultáneos y espacio libre

En ambos casos puedes configurar CPU, memoria, disco y red. Un límite no garantiza rendimiento cuando el host está sobreasignado. Monitorea el nodo y cada carga; esta guía de Grafana y Prometheus para servidores puede complementar las gráficas integradas cuando necesites histórico y alertas.

3. Aislamiento y seguridad

La VM presenta una frontera de hardware virtual. Una vulnerabilidad dentro del invitado todavía puede comprometer datos del propio invitado o servicios accesibles por red, pero para llegar al host necesita atravesar mecanismos adicionales del hipervisor. Por eso suele ser la elección prudente para cargas no confiables, software expuesto o entornos con requisitos de separación estrictos.

En LXC, los procesos comparten el kernel del host. Una vulnerabilidad del kernel que permita escapar del contenedor afecta esa frontera. Esto no significa que todo contenedor sea inseguro: namespaces, cgroups, AppArmor, seccomp, capabilities y los controles de Proxmox reducen superficie y privilegios. Significa que el modelo de riesgo es distinto.

Proxmox recomienda contenedores no privilegiados. En ellos, el usuario root del contenedor se mapea a un usuario sin privilegios en el host mediante user namespaces. Un contenedor privilegiado tiene un mapeo más directo y eleva el impacto de errores de configuración. Evítalo salvo que una necesidad técnica concreta esté documentada y hayas evaluado sus consecuencias.

Comprueba la configuración de un contenedor desde el nodo:

pct config 101

Una línea como unprivileged: 1 indica el modo no privilegiado. No edites manualmente los mapas de UID/GID copiando ejemplos sin adaptarlos; un bind mount con permisos incorrectos puede exponer más datos de los previstos.

Reglas prácticas:

no entregues dispositivos del host a un contenedor por comodidad;
evita montar sockets administrativos, como el de Docker, dentro de cargas no confiables;
aplica actualizaciones al host y a cada espacio de usuario;
segmenta redes y limita puertos aunque exista aislamiento local;
usa cuentas y API tokens con permisos mínimos en Proxmox.

4. Compatibilidad de sistemas y kernel

Una VM permite instalar su propio kernel y, si el hardware virtual lo admite, sistemas operativos que no usan Linux. Es apropiada para Windows, appliances distribuidos como ISO, pruebas de kernels, módulos especiales y configuraciones que esperan controlar el arranque completo.

LXC ejecuta distribuciones Linux que pueden trabajar con el kernel del host. El espacio de usuario puede ser Debian, Ubuntu, Alpine u otra plantilla disponible, pero no puedes arrancar un kernel arbitrario dentro del contenedor como si fuera una VM. Algunas llamadas o funciones están filtradas, y los módulos se cargan en el host, no de manera independiente dentro del contenedor.

El catálogo disponible puede verse y actualizarse desde la interfaz o con:

pveam update
pveam available

Descarga una plantilla al almacenamiento que admita vztmpl:

pveam download local NOMBRE-DE-PLANTILLA

Usa un nombre obtenido del listado actual, no uno inventado. Para crear una VM, en cambio, subes una ISO oficial y sigues el instalador del proveedor.

Elige VM cuando el fabricante solo soporta su appliance, exige un kernel concreto o proporciona controladores propios. Elige LXC cuando la aplicación es un servicio Linux convencional, su documentación es compatible con contenedores de sistema y no necesita modificar el kernel.

5. Almacenamiento, red y acceso a dispositivos

Los dos tipos pueden conectarse a puentes como vmbr0, usar VLAN y almacenar datos en backends admitidos por Proxmox. Sin embargo, el formato y la manera de presentar recursos cambian.

Una VM ve discos y adaptadores virtuales. El host puede usar VirtIO SCSI o VirtIO Block, mientras el invitado administra particiones y sistemas de archivos. Esta capa facilita que el sistema invitado crea que controla un disco propio.

LXC recibe un root filesystem y puntos de montaje. Proxmox puede administrar volúmenes asociados al contenedor, incluirlos en backups y aplicar cuotas según el backend. Los bind mounts apuntan a rutas del host y requieren especial cuidado: su contenido puede no formar parte de la copia estándar y los permisos dependen de los mapeos de usuarios.

Necesidad	Preferencia habitual
Appliance con imagen de disco	VM
Compartir una ruta concreta del host	LXC, con bind mount evaluado
Cifrado y particionado controlado por invitado	VM
Servicio Linux con volumen administrado	LXC
PCI passthrough completo	VM
Acceso limitado a dispositivo	Posible en LXC, con mayor exposición

Para la red, un contenedor suele usar una interfaz virtual enlazada al puente. Puedes consultar su estado con:

pct config 101
pct exec 101 -- ip address show

Una VM usa una tarjeta virtual configurada con qm. El sistema invitado decide su IP, salvo integraciones como cloud-init:

qm config 200

No abras la consola web ni SSH de los invitados a Internet sin una VPN o controles específicos. La separación entre invitados no reemplaza firewall, actualizaciones ni autenticación.

6. Docker, Kubernetes y contenedores anidados

Docker y LXC resuelven problemas relacionados, pero no idénticos. LXC se usa aquí como contenedor de sistema: puede ejecutar init, varios servicios y una distribución completa de espacio de usuario. Docker empaqueta aplicaciones e imágenes con su propio flujo de construcción y distribución.

Es técnicamente posible ejecutar Docker dentro de un LXC, pero puede requerir funciones de nesting, ajustes de almacenamiento y permisos. Cada excepción debilita o complica el aislamiento. Si el objetivo es aprender Docker, usar funciones avanzadas del kernel o seguir una arquitectura soportada por el proveedor, una VM Linux dedicada suele ofrecer una frontera y un comportamiento más previsibles.

Para habilitar características en un contenedor existente hay comandos como:

pct set 101 -features nesting=1

No lo ejecutes por rutina. Lee qué necesita la aplicación y documenta por qué se habilitó. Evita convertir un contenedor no privilegiado en privilegiado solo para solucionar un error de permisos.

Kubernetes también espera controlar redes, cgroups, montajes y otros componentes. Un laboratorio puede funcionar dentro de LXC con ajustes, pero las diferencias respecto a nodos VM pueden producir problemas difíciles de diagnosticar. Si tu meta es practicar una instalación reproducible o acercarte a un entorno de servidores independientes, usa varias VM. Para alojar una aplicación sencilla ya contenerizada, una VM Docker puede ser más fácil de respaldar y migrar como unidad.

7. Operación diaria, snapshots y copias

Proxmox ofrece comandos paralelos: pct administra contenedores y qm administra máquinas virtuales.

pct list
pct start 101
pct shutdown 101
qm list
qm start 200
qm shutdown 200

Prefiere apagados ordenados. pct stop o qm stop deben reservarse para invitados que no responden, pues pueden interrumpir escrituras.

Los snapshots capturan un estado en un almacenamiento compatible, pero no son copias independientes. En una VM, la coherencia de aplicaciones depende del estado del invitado y de integraciones como QEMU Guest Agent. En LXC, también debes considerar bases de datos y procesos con datos en memoria. Para cambios delicados, detén limpiamente el servicio o usa sus mecanismos de consistencia.

vzdump crea backups de VM y contenedores mediante una interfaz común. Un ejemplo hacia un almacenamiento configurado llamado backup-store es:

vzdump 101 --storage backup-store --mode snapshot
vzdump 200 --storage backup-store --mode snapshot

No uses local como única copia si está en el mismo disco físico que los invitados. Comprueba qué puntos de montaje entran en el backup LXC y prueba restauraciones. Para archivos de aplicación puede tener sentido añadir backups cifrados con Restic, siempre como capa complementaria y con credenciales protegidas.

8. Casos de uso y árbol de decisión

LXC encaja bien en servicios Linux confiables y compactos: DNS interno, proxy inverso, servidor web, automatización doméstica compatible o herramientas de monitorización. Una VM encaja mejor en firewalls virtuales, Windows, appliances, laboratorios de kernels, nodos Kubernetes y servicios que reciben código no confiable.

Haz estas preguntas en orden:

¿El invitado necesita un sistema no Linux o un kernel propio? Usa VM.
¿El proveedor entrega y soporta una ISO o appliance? Usa VM.
¿La carga es no confiable o requiere separación fuerte? Prefiere VM.
¿Necesita passthrough o modificar funciones sensibles del kernel? Prefiere VM.
¿Es un servicio Linux convencional y confiable, con recursos limitados? Considera LXC no privilegiado.
¿La operación será más simple en una VM aunque consuma algo más? Elige simplicidad.

Caso	Opción inicial	Motivo
Pi-hole o DNS interno	LXC no privilegiado	Servicio Linux pequeño
Servidor Windows	VM	Kernel y SO propios
Docker para aprendizaje	VM Linux	Menos excepciones de nesting
Appliance de firewall	VM	Imagen y dispositivos propios
Web estática interna	LXC no privilegiado	Poca sobrecarga
Código de terceros dudoso	VM	Mejor frontera de aislamiento

No conviertas densidad en el único objetivo. Diez servicios distribuidos sin documentación pueden ser más difíciles de recuperar que tres VM bien agrupadas. Define nombres, VMID/CTID, direcciones, propietarios de datos y política de backup.

Conclusiones

LXC prioriza eficiencia al compartir el kernel Linux; KVM prioriza separación y compatibilidad mediante un sistema invitado completo. Ninguna opción gana siempre. La carga, el nivel de confianza y el soporte del proveedor deben pesar más que ahorrar unos recursos.

En un homelab, una regla útil es empezar con LXC no privilegiado para servicios Linux sencillos y confiables, y usar VM para appliances, otros sistemas, Docker complejo o cargas expuestas. Si aparecen muchas excepciones, el diseño está indicando que debes cambiar de modelo.

Preguntas frecuentes

¿Por qué LXC vs máquinas virtuales en Proxmox: cuándo usar cada uno es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con LXC vs máquinas virtuales en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con LXC vs máquinas virtuales en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar LXC vs máquinas virtuales en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a LXC vs máquinas virtuales en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.