Historical Proxmox VE 7.4 LXC container guide with current Proxmox VE 9.2 notes.
Proxmox VE can run both QEMU/KVM virtual machines and Linux LXC containers. Both isolate workloads, but they do so at different layers.
A virtual machine has its own kernel. An LXC container shares the Linux kernel of the Proxmox host and isolates processes, users, networking, resources, and filesystems through namespaces, cgroups, AppArmor, seccomp, and other kernel mechanisms.
This gives containers very low overhead and fast startup, but they can only run compatible Linux systems. Windows and FreeBSD cannot run inside a normal Proxmox LXC container.
Proxmox classifies these guests as system containers: they contain a complete Linux userspace with init, services, users, and packages. They are not the same thing as an application container such as a Docker container.
For comparison, see our Proxmox VE virtual-machine guide and our introduction to virtualization.
Proxmox VE 9.2 was released in May 2026 and includes LXC 7.0. The GUI workflow remains very similar to the one shown in these screenshots, but modern deployments should pay particular attention to:
nesting, keyctl, FUSE, and device access;A Proxmox CT is intended to behave like a small Linux server. Docker and Podman normally provide application containers.
Docker can run inside some LXC setups by enabling features such as nesting and, in some unprivileged configurations, keyctl. However, Proxmox documentation recommends a QEMU VM for application-container engines when stronger isolation and fewer dependencies on the host kernel are important.
Do not enable nesting, keyctl, FUSE, extra mount capabilities, or device access “just in case.” Each additional capability weakens part of the container boundary.
Containers are usually created from templates. The target storage must allow the Container template or vztmpl content type.
The web interface can upload an existing template, download one from a URL, or open the catalog maintained through the Proxmox Appliance Manager.
The same catalog is available from the CLI:
pveam update
pveam availableand a template can be downloaded with:
pveam download local TEMPLATE_NAMEProxmox integrates with distributions such as Debian, Ubuntu, Alpine, Fedora, Arch Linux, openSUSE, Gentoo, Rocky/AlmaLinux, and others. The exact template versions change over time, so check the current catalog instead of assuming an older release is still available.
The equivalent workflow in Proxmox VE 9.2 remains very similar.
The CT ID must be unique across the cluster. IDs below 100 are reserved internally, so normal containers use IDs beginning at 100.
The hostname should fit the DNS naming policy of the network.
A root password can be configured, but current Proxmox also makes it easy to provide an SSH public key at creation time. For remote administration, key-based authentication is normally preferable.
This is one of the most important security choices.
In an unprivileged container, UID 0 inside the CT is mapped through user namespaces to an unprivileged UID on the Proxmox host. This reduces the impact of many potential container escapes and resource-abuse bugs.
Proxmox uses unprivileged containers as the normal default in the GUI and recommends them for most workloads.
A privileged container can be easier when a workload needs unusual filesystems, devices, or permission semantics, but the security boundary is weaker. Use it only when you understand the requirement.
The template contains a prepared Linux filesystem. It is not an ISO that needs to go through a normal installation process.
After creation, treat the CT like any other server: update packages and apply the distribution’s security policy.
Choose an appropriate managed storage backend and rootfs size.
The old guide recommended noatime as a general performance tweak. It can reduce access-time writes, but modern filesystems already use policies such as relatime, so there is no need to force it on every CT.
The more important decision is the backend itself. ZFS, LVM-thin, Ceph, and directory storage have different snapshot, replication, and thin-provisioning behavior.
A CT can also receive additional mount points. Proxmox distinguishes between:
Bind mounts require special care: their contents are not included in normal vzdump backups. They can also create UID/GID permission issues in unprivileged containers.
Do not bind-mount sensitive host paths such as /, /etc, or /var into a container.
A container does not receive emulated virtual CPUs in the same way as a VM. Container processes are scheduled directly by the host Linux scheduler.
The Cores value restricts how many CPUs the CT can use. If no core restriction is set, the container can use all available CPUs subject to the remaining scheduler and cgroup limits.
CPU limit and CPU weight settings can further control how much processor time a container receives during contention.
Containers share host physical memory and enforce limits through cgroups. There is no separately emulated RAM device in the VM sense.
The memory setting limits RAM consumption by CT processes. The swap value controls how much swap the CT may consume under host policy.
Containers are lightweight, but aggressive overcommit can still exhaust the host and affect every guest on the node.
The CT normally receives a veth interface connected to a Proxmox bridge such as vmbr0.
Depending on the design, configure static IPv4, DHCP, IPv6, VLAN tagging, Proxmox firewall integration, and rate limiting.
Do not copy addresses from screenshots. The IP prefix and gateway must match your own network.
If search domain and nameserver are left unset, Proxmox can inherit those values from the host.
Enterprise and lab networks may depend on internal DNS for Active Directory, LDAP, service discovery, or split-horizon zones, so public resolvers should not be substituted automatically.
Check the CT ID, hostname, privilege model, template, storage, CPU, memory, bridge, IP/VLAN/gateway, DNS, and whether the CT should start automatically when creation completes.
A CT is normally created much faster than a traditional OS installation because the template already contains a prepared userspace.
From here, manage resources, networking, DNS, startup options, backups, snapshots, replication, firewall rules, and permissions.
A snapshot normally depends on the same storage that holds the CT. If that storage fails, snapshots can be lost with it. Backups should live on separate, appropriately protected storage.
The presence of a Replication menu does not mean every CT can be replicated through every backend. Integrated Proxmox replication depends on the storage and cluster design, with local ZFS being a common case.
Managed volumes can be included in vzdump according to their configuration. Bind mounts are not backed up as part of the CT backup and require an independent data-protection plan.
After starting the CT, use the web console, SSH, or enter its namespaces directly from the host:
pct enter CTIDDisplay its Proxmox configuration with:
pct config CTIDThe template may be older than the latest security updates. On Debian or Ubuntu, for example:
apt update
apt full-upgradeThen install only the services that the CT actually needs.
Under container features, Proxmox can expose additional capabilities.
nesting enables certain nested-container scenarios, but exposes more host procfs and sysfs information to the guest.
keyctl allows kernel keyring operations and may be needed for some Docker setups inside an unprivileged CT.
FUSE and extra mount types also have security and backup implications.
The safest approach is least privilege: enable only the feature required by the workload.
This is popular in home labs and can work, especially in carefully configured unprivileged containers.
However, “works” is not the same as “recommended everywhere.” Proxmox recommends a QEMU VM for application-container platforms when you want strong isolation, a dedicated guest kernel, and predictable compatibility with Docker or Kubernetes.
Traditional Linux services—DNS, reverse proxies, web services, monitoring, internal tools—can be excellent LXC workloads. Software that expects deep control of namespaces, cgroups, netfilter, kernel modules, or device access is often easier to operate inside a VM.
| LXC | QEMU/KVM VM |
|---|---|
| Linux only | Linux, Windows, BSD, and other guest OSes |
| Shares the host kernel | Own guest kernel |
| Very low overhead | Stronger isolation |
| Very fast startup | Full operating-system boot |
| Excellent for many Linux services | Best for workloads needing a private kernel or stronger boundary |
| Special hardware/features may need additional host integration | Virtual devices and PCI passthrough provide a more independent hardware model |
Containers can migrate between cluster nodes, but this is not the same as transparent VM live migration.
Proxmox supports restart migration workflows that can reduce service interruption, but the CT is stopped or restarted during part of the operation.
The screens are still useful because the LXC wizard has evolved incrementally. What needs updating is the technical interpretation around security, storage, backup behavior, and container features—not the historical screenshots themselves.
Learn PHP 8.5 from scratch: syntax, databases, Composer, PSR, Laravel, Symfony, modern runtimes, APIs, security,…
Step-by-step guide to installing VirtualBox Guest Additions 7.2.20 on Linux: kernel headers, modules, Secure Boot,…
An introduction to Kali Linux 2026.2: authorized security testing, rolling updates, APT changes, virtual machines,…
A practical guide to software test automation: unit, integration, API, contracts, Selenium, Playwright, Cypress, Appium,…
A complete networking roadmap for future sysadmins: Ethernet, IPv4/IPv6, subnetting, VLANs, routing, DNS, DHCP, Linux,…
History and architecture of Evelyn Berezin’s United Airlines reservation system, distinguishing it from the earlier…