LXC vs KVM in Proxmox: Container or VM?

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). 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.

Performance and resources

Under pure CPU load both technologies sit close to bare metal: LXC reaches practically native speed, and KVM, thanks to hardware acceleration, typically around 97 to 99 percent. The real difference is 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.

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. 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. 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. If you want maximum isolation and containers at the same time, you can nest LXC inside a KVM VM, which the Proxmox documentation also recommends.

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.

Versions and current state

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 is supported until 31 August 2026. The fundamental separation of LXC and KVM has held unchanged across many versions.

Operations and support

LXC or KVM is rarely a matter of taste. It depends on security requirements, the operating system, density and availability. We run Proxmox in production for customers and decide this per workload, including storage choice, isolation and the HA concept. If you want a well-founded design or ongoing operations, see our services for Proxmox and Private Cloud or book a free initial consultation.