Proxmox VE permite ejecutar máquinas virtuales QEMU/KVM y contenedores Linux LXC. Ambos modelos sirven para aislar cargas, pero funcionan de manera diferente.
Una máquina virtual ejecuta su propio kernel. Un contenedor LXC comparte el kernel Linux del host Proxmox y aísla procesos, usuarios, red, recursos y sistema de archivos mediante namespaces, cgroups, AppArmor, seccomp y otras primitivas del kernel.
Por eso los contenedores tienen muy poco overhead y arrancan rápidamente, pero solo pueden ejecutar sistemas Linux compatibles. No podemos ejecutar Windows o FreeBSD dentro de un contenedor LXC de Proxmox.
Proxmox denomina a estos entornos system containers: contienen un sistema Linux completo con init, servicios, usuarios y paquetes. No son lo mismo que un contenedor de aplicación Docker.
Si quieres comparar ambos modelos, consulta cómo crear una máquina virtual en Proxmox VE y nuestra introducción a la virtualización.
Qué cambió desde Proxmox VE 7.4
Proxmox VE 9.2 fue publicado en mayo de 2026 y utiliza LXC 7.0. El asistente continúa siendo muy parecido al que muestran estas capturas, pero hoy conviene prestar especial atención a:
- contenedores no privilegiados como opción recomendada;
- autenticación mediante clave SSH además de contraseña;
- features como
nesting,keyctl, FUSE y dispositivos; - mount points y bind mounts;
- qué volúmenes entran realmente en backups;
- compatibilidad de snapshots y replicación con el almacenamiento;
- el hecho de que Docker dentro de LXC no es la arquitectura que Proxmox recomienda como primera opción.
LXC frente a Docker: no son la misma capa
Un CT de Proxmox pretende comportarse como un pequeño servidor Linux completo. Docker y Podman, en cambio, se orientan normalmente a application containers.
Es técnicamente posible ejecutar Docker dentro de determinados contenedores LXC activando funciones como nesting y, en algunos escenarios no privilegiados, keyctl. Sin embargo, la propia documentación de Proxmox recomienda ejecutar motores de contenedores de aplicaciones dentro de una VM QEMU cuando buscamos un aislamiento más fuerte y menos dependencias con el host.
No deberíamos activar nesting, keyctl, FUSE o acceso a dispositivos simplemente “por si acaso”: cada capacidad adicional reduce parte del aislamiento del contenedor.
1. Gestionar plantillas LXC
Los contenedores se crean normalmente a partir de templates. El almacenamiento debe permitir el tipo de contenido Container template o vztmpl.
Desde la interfaz podemos subir una plantilla existente, descargarla desde una URL o abrir el catálogo que Proxmox obtiene mediante su Appliance Manager.
Por CLI, las mismas operaciones pueden consultarse con:
pveam update
pveam availabley una plantilla se descarga, por ejemplo, con:
pveam download local NOMBRE_DE_LA_PLANTILLA
Proxmox mantiene soporte de integración para distribuciones como Debian, Ubuntu, Alpine, Fedora, Arch Linux, openSUSE, Gentoo, Rocky/AlmaLinux y otras. La lista concreta cambia con el tiempo, por lo que debemos consultar el catálogo actual antes de asumir que una versión antigua sigue disponible.
2. Abrir “Crear CT”
En Proxmox VE 9.2 el flujo sigue siendo muy parecido.
3. General: CT ID, hostname, contraseña, SSH y privilegios
El CT ID es único en todo el clúster. Los identificadores menores que 100 están reservados internamente, por lo que los CT normales utilizan IDs a partir de 100.
El hostname debe ser coherente con el DNS de nuestra red.
Podemos establecer una contraseña de root, pero para servidores administrados remotamente resulta preferible añadir también una clave pública SSH. Las versiones actuales permiten introducirla directamente durante la creación.
Contenedor no privilegiado
Esta es una de las decisiones de seguridad más importantes.
En un contenedor no privilegiado, el UID 0 que representa a root dentro del CT se traduce a un usuario sin privilegios en el host mediante user namespaces. Esto reduce notablemente el impacto de muchas posibles fugas del contenedor.
Proxmox utiliza el modo no privilegiado como opción predeterminada en la creación desde la interfaz y lo recomienda para la mayoría de las cargas.
Un contenedor privilegiado ofrece mayor compatibilidad con ciertos dispositivos, filesystems o aplicaciones especiales, pero tiene una superficie de riesgo mayor. Debe utilizarse únicamente cuando sabemos por qué lo necesitamos.
4. Template
La plantilla contiene un filesystem preparado para arrancar como contenedor, no una ISO que tenga que pasar por un instalador tradicional.
Después de crear el CT debemos tratarlo igual que cualquier servidor: actualizar paquetes y aplicar las políticas de seguridad de la distribución.
5. Root Disk
Seleccionamos el backend que almacenará el rootfs y fijamos un tamaño adecuado.
La opción noatime reduce actualizaciones del tiempo de acceso a archivos y puede disminuir escrituras, pero no es una optimización que necesitemos forzar en todos los CT. Las políticas modernas del sistema de archivos y relatime ya reducen buena parte de ese coste.
Más importante que perseguir microoptimizaciones es elegir correctamente el backend: ZFS, LVM-thin, Ceph o directory storage ofrecen características diferentes para snapshots, thin provisioning y replicación.
Mount points: una capacidad muy útil
Además del rootfs, un contenedor puede tener puntos de montaje adicionales.
Proxmox distingue entre:
- storage-backed mount points, gestionados por el sistema de almacenamiento de Proxmox;
- bind mounts, que exponen un directorio del host dentro del CT;
- device mounts, para casos especiales.
Los bind mounts requieren especial atención: su contenido no se incluye en un backup normal con vzdump. También pueden generar problemas de permisos en contenedores no privilegiados debido al mapeo de UID/GID.
No debemos bind-mountar directorios sensibles del host como /, /etc o /var dentro de un contenedor.
6. CPU
Un CT no recibe CPUs virtuales emuladas como una VM. Sus procesos son planificados directamente por el scheduler Linux del host.
La opción Cores limita cuántos procesadores puede utilizar. Si no fijamos ese límite, el contenedor puede utilizar todos los cores disponibles según el resto de límites y el scheduler.
También existen parámetros de límite de CPU y peso relativo para controlar cuánto tiempo de procesador recibe un CT cuando hay contención.
7. Memoria y swap
Los contenedores comparten la memoria física del host y sus límites se aplican mediante cgroups. No existe una región de RAM “reservada físicamente” del mismo modo que suele conceptualizarse una VM.
El valor de memoria define el límite de RAM para los procesos del CT. Swap establece cuánta memoria intercambiable puede consumir bajo las políticas del host.
No conviene sobreaprovisionar de forma agresiva. Aunque los CT son ligeros, todos compiten por los mismos recursos del nodo.
8. Red
La interfaz del CT es normalmente un par veth conectado a un bridge de Proxmox como vmbr0.
Podemos utilizar:
- IPv4 estática;
- DHCP;
- IPv6 estática;
- SLAAC/DHCPv6 según el diseño;
- VLAN tag;
- firewall de Proxmox;
- rate limit.
No copies las direcciones de las capturas. IP, prefijo y gateway deben corresponder a tu red.
9. DNS
Si no especificamos search domain ni nameserver, Proxmox puede heredar esos valores del host.
En redes empresariales no debemos sustituir automáticamente el DNS interno por resolvers públicos: Active Directory, LDAP, servicios internos y split DNS pueden depender de la resolución corporativa.
10. Confirmar
Antes de finalizar revisamos:
- CT ID y hostname;
- modo privilegiado/no privilegiado;
- template;
- almacenamiento y tamaño;
- CPU y RAM;
- bridge, IP, VLAN y gateway;
- DNS;
- si debe iniciarse automáticamente al terminar.
11. Crear el contenedor
Un CT se crea mucho más rápido que una instalación tradicional porque la plantilla ya contiene el sistema base.
12. Recursos y opciones del CT
Desde aquí administramos recursos, red, DNS, opciones de arranque, backups, snapshots, replicación, firewall y permisos.
Snapshots no son backups
Un snapshot depende del mismo almacenamiento que contiene el CT. Si ese almacenamiento falla, el snapshot puede perderse con él. Un backup debe almacenarse en otra ubicación apropiada, idealmente con una política independiente de retención.
Replicación depende del almacenamiento
La opción de replicación no significa que cualquier CT pueda replicarse de cualquier manera. En Proxmox la replicación integrada depende del backend y la configuración del clúster; ZFS local es el caso más habitual.
Backups y mount points
Los volúmenes gestionados pueden incluirse en vzdump según su configuración. Los bind mounts no se respaldan como parte de ese backup, por lo que necesitan una estrategia de copia separada.
13. Arrancar y abrir la consola
Una vez iniciado podemos entrar desde la consola web, por SSH si lo hemos configurado o desde el host mediante:
pct enter CTIDTambién podemos consultar la configuración:
pct config CTIDActualizar el sistema nada más crearlo
La plantilla puede tener paquetes anteriores a las últimas actualizaciones de seguridad. Después del primer arranque actualizamos la distribución.
Por ejemplo, en Debian/Ubuntu:
apt update
apt full-upgradeDespués instalamos únicamente los servicios necesarios.
Nesting, keyctl, FUSE y dispositivos: no activar sin necesidad
En Options → Features podemos habilitar capacidades adicionales.
nesting permite determinados niveles de contenedores dentro del CT, pero expone más información de procfs y sysfs del host.
keyctl permite determinadas llamadas al keyring del kernel y puede ser necesario para algunas configuraciones de Docker dentro de un CT no privilegiado.
FUSE y el montaje de filesystems adicionales también tienen implicaciones de seguridad y backup.
El criterio correcto es mínimo privilegio: activar únicamente la función que nuestra carga realmente necesita.
¿Docker dentro de LXC?
Es un escenario popular en laboratorios domésticos y puede funcionar, especialmente con contenedores no privilegiados y opciones de nesting cuidadosamente configuradas.
Pero debemos distinguir “funciona” de “es la arquitectura recomendada para todo”. Proxmox recomienda una VM QEMU para application containers cuando necesitamos aislamiento fuerte, compatibilidad completa con Docker/Kubernetes y un kernel independiente.
Para un servicio Linux tradicional —DNS, proxy, web, monitorización, herramientas internas— un CT LXC puede ser extremadamente eficiente. Para plataformas que esperan controlar profundamente namespaces, cgroups, iptables/nftables, módulos o dispositivos, una VM suele ser más predecible.
¿Cuándo elegir LXC y cuándo una VM?
| LXC | VM QEMU/KVM |
|---|---|
| Linux exclusivamente | Linux, Windows, BSD y otros sistemas |
| Comparte kernel del host | Kernel propio |
| Muy poco overhead | Mayor aislamiento |
| Arranque muy rápido | Boot completo del sistema |
| Ideal para muchos servicios Linux | Ideal para software que necesita kernel propio o aislamiento fuerte |
| Acceso a hardware/funciones especiales puede requerir configuración adicional | PCI passthrough y dispositivos virtuales con un modelo más independiente |
Migración de contenedores
Los contenedores pueden migrarse entre nodos de un clúster, pero no debemos confundirlo con la live migration transparente de una VM.
Proxmox puede realizar migraciones con reinicio y reducir el downtime a un intervalo corto, pero el CT debe detenerse o reiniciarse durante parte del proceso.
Una configuración razonable en Proxmox VE 9.2
Para un servidor Linux ligero moderno, un buen punto de partida es:
- contenedor no privilegiado;
- template oficial actualizado de Debian/Ubuntu/Alpine según la carga;
- clave SSH administrativa;
- CPU y RAM limitadas de acuerdo con el servicio;
- rootfs sobre almacenamiento gestionado por Proxmox;
- veth conectado al bridge adecuado;
- firewall habilitado cuando se utilice la política de firewall de Proxmox;
- sin nesting/keyctl/FUSE salvo necesidad;
- backups programados en almacenamiento independiente;
- documentación de cualquier bind mount externo.
Por qué conservar esta guía de Proxmox VE 7.4
Las pantallas siguen siendo útiles porque el asistente ha evolucionado de forma incremental. Lo importante es no trasladar automáticamente todas las recomendaciones de 2023 a un host actual.
Por eso mantenemos las capturas originales y hemos actualizado el contexto técnico alrededor de cada decisión.
Continuar con la serie
- Crear una máquina virtual en Proxmox VE paso a paso
- Introducción actualizada a Proxmox VE 9.2
- Instalación histórica de Proxmox VE 7.4
