LXC vs VM in Proxmox: Container or Virtual Machine (KVM)?

Proxmox VE gives you two ways to virtualize workloads: LXC containers and KVM virtual machines. The decisive difference is the kernel. An LXC container shares the Proxmox host Linux kernel, which makes it very lightweight, starts in seconds and uses little RAM, but it can only run Linux. A KVM VM virtualizes full hardware and brings its own kernel, so it can run any operating system including Windows and is more strongly isolated from the host, at the cost of a little more overhead. You manage both types in the same Proxmox interface. The rule of thumb: LXC for many small Linux services, KVM for Windows, foreign kernels, strong isolation and live migration.

This article is part of our Proxmox knowledge base. For what Proxmox itself is, see What is Proxmox. If you want to compare LXC with Docker, read Proxmox vs Docker.

The core difference: shared kernel vs own kernel

The architecture explains almost every other difference.

LXC (Linux Containers) is operating-system-level virtualization. At its core the container is an isolated user space running on the host kernel. Separation comes from Linux namespaces (processes, network, filesystem, users) and cgroups (resource limits). There is no second kernel, no emulated hardware and no boot process in the classic sense. That makes containers lean, fast and memory-friendly, but ties them to the host's kernel and architecture.

KVM (Kernel-based Virtual Machine) is hardware virtualization. QEMU provides virtual hardware and KVM accelerates it through the CPU's virtualization features (Intel VT-x, AMD-V) (KVM documentation in the Linux kernel). The VM boots a full operating system with its own kernel, its own drivers and its own memory space. Ideally the guest does not know it is virtualized and is separated from the host by the hypervisor boundary.

LXC: Host-Kernel -> [Userspace A] [Userspace B]
KVM: Hypervisor -> [Kernel A + Userspace A] [Kernel B + Userspace B]

Performance: LXC versus VM

LXC shares the host kernel, while KVM uses hardware acceleration. Actual throughput depends on the workload, drivers and storage; percentages require measurements. Differences include I/O, overhead and density:

• RAM: An LXC container only consumes the memory of its running processes. A VM additionally reserves memory for its own kernel and the emulated hardware. On the same host you can therefore run substantially more containers than VMs.
• Startup time: Containers start in fractions of a second because no kernel is booted. A VM goes through a full boot process.
• Storage and I/O overhead: Containers access the filesystem directly through the host kernel. VMs use virtual disks and virtual drivers (VirtIO), which adds a small amount of overhead.

In practice: if you want to run 50 small Linux services, containers are denser and leaner. If you run few, large or mixed workloads, you often benefit more from the flexibility of a VM.

Illustrative calculation with assumed values: 50 services with an assumed 256 MiB process memory each need 12.5 GiB in total. Assuming another 256 MiB per VM for the guest kernel and base services gives 25 GiB. Both designs additionally need host memory, cache and reserves; measure actual values.

Operating systems: Windows only in KVM

This is the hardest deciding factor. Because LXC reuses the host's Linux kernel, only Linux distributions run inside it (Debian, Ubuntu, Rocky, Alpine and so on). Windows, Windows Server, BSD systems or appliances with their own kernel run in Proxmox only as KVM VMs. The same applies if you need special kernel modules, a different kernel branch or a real-time kernel: there is no way around a VM. Containers always share exactly the kernel that the Proxmox host runs.

Isolation and security: privileged vs unprivileged LXC

This is the most important security difference. A KVM VM is strongly isolated by the hypervisor boundary: escaping to the host requires a vulnerability in the hypervisor itself, which is very rare with KVM. A compromised guest kernel stays inside the guest.

An LXC container shares the host kernel. A kernel vulnerability is therefore a potential entry point for all containers and the host. Proxmox mitigates this with two container modes:

• Unprivileged containers (default and recommended): All UIDs and GIDs are mapped into a different range. Root inside the container (UID 0) is mapped to an unprivileged UID on the host, typically 100000 (Proxmox container documentation). A successful escape would therefore only affect a low-privilege host user, not root. On top of that, AppArmor profiles, seccomp filters and namespaces apply.
• Privileged containers: Root inside the container is also root on the host. If a process escapes through a kernel flaw, a misconfigured mount or an LXC bug, it runs with root privileges on the Proxmox host. The LXC project explicitly does not treat escapes from privileged containers as CVE-worthy security issues (LXC security documentation). Privileged containers therefore belong only in trusted environments, for example when a container strictly needs NFS or CIFS mounts.

For untrusted or multi-tenant workloads, the VM is the more robust choice. For application containers (OCI/Docker) requiring strong isolation and live migration, the Proxmox documentation recommends running them inside a QEMU VM.

Live migration, snapshots and backup

A difference that quickly matters in cluster operation:

• Live migration: Proxmox supports true live migration without downtime only for KVM VMs. You move running VMs between nodes without interruption, for example for maintenance or updates. LXC containers have no live migration. They are moved via restart migration: stop briefly, move to the target node, start there. That means a short, schedulable downtime. With shared or replicated storage it is very fast.
• Snapshots: Both types support snapshots if the storage allows it. On ZFS, Ceph or LVM-thin you can freeze and roll back containers and VMs. On plain directory storage without snapshot capability this is limited.
• Backup: You back up both types with vzdump or the Proxmox Backup Server, deduplicated, incremental and encrypted. Note that the contents of bind mounts are not included in container backups.

If high availability with non-disruptive maintenance is the goal, these points clearly favor KVM.

Decision table: when LXC, when KVM

Short version: default to LXC for lightweight Linux services, and choose KVM whenever one of these applies: Windows or non-Linux, a custom kernel, high isolation requirements, or live migration without downtime.

Docker: inside LXC or a VM?

Docker runs application containers, while LXC provides full Linux user spaces. A QEMU VM is the documented path for Docker requiring strong isolation and live migration. Docker inside LXC still shares the host kernel and requires reviewing nesting and permissions. Proxmox vs Docker explains the difference from OCI images used directly in Proxmox.

Versions and current state

Since Proxmox VE 9.1, containers can also be created from OCI images. The Proxmox documentation describes application containers as a technology preview; see the Docker comparison.

These statements refer to current Proxmox versions. Proxmox VE 9.2 (released in May 2026, based on Debian 13) is the current generation, while Proxmox VE 8 reached end of life in August 2026 (support lifecycle, as of October 2026). The fundamental separation of LXC and KVM has held unchanged across many versions.

Design for your workloads

We select LXC or KVM per workload together with storage, isolation and the HA design: through Proxmox consulting before setup and Managed Proxmox during operations. An initial consultation clarifies the scope.

Further reading: HA · Storage · Kubernetes · GPU-Passthrough · PBS · Sizing.

For the KVM guest workflow, see create a Proxmox VM: Ubuntu, Linux and Windows.

For the platform question see Proxmox versus a custom KVM/libvirt stack; this differs from selecting a guest type.