An LXC container is the right pick when you need an ordinary Linux service and memory savings matter. A virtual machine is needed when you require a different kernel, your own kernel, or full isolation from the host.
How a container and a virtual machine differ inside
A container shares one kernel with the host: processes inside it are visible to the system just like ordinary processes, only separated by namespaces. A virtual machine boots its own kernel and knows almost nothing about the host besides the virtual hardware it was shown.
- a container starts almost instantly because it does not boot a separate kernel
- a container cannot run a different operating system or a different kernel version
- a virtual machine is isolated more strongly because it shares a kernel with neither the host nor its neighbors
The basic concepts of the platform are covered in the article on what Proxmox VE is.
Choice table: what to check
For a specific service the decision usually comes down to a few practical criteria rather than a general "which is better".
| Criterion | LXC | Virtual machine |
|---|---|---|
| Memory use | lower, memory is not reserved whole in advance | higher, memory is allocated for the guest OS |
| Startup speed | almost instant | a full kernel and service boot |
| Own kernel | no, shared with the host | yes, separate |
| Kernel modules | limited, depend on the host kernel | any that fit the guest OS |
| Windows | not possible | yes |
| Device passthrough | limited, via bind-mount | full PCI and USB passthrough |
| Migration | simpler and faster | live migration is possible |
| Isolation | at the kernel namespace level | at the virtual hardware level |
What usually goes into a container
A container fits services without special requirements for the kernel or their own operating system:
- web servers and reverse proxies
- databases without specific kernel modules
- network services such as DNS or DHCP
- monitoring and log collection systems
- lightweight utility services and task schedulers
What absolutely needs a virtual machine
Some tasks a container simply cannot handle, because it lacks its own kernel or isolation:
- any non-Linux system, Windows included
- a custom kernel or kernel modules different from the host kernel
- nested virtualization inside the guest
- passthrough of disks and graphics cards in a mode a container cannot offer
- services that need full isolation from the rest of the workloads on the node
Why virtual machines are "slow"
A complaint about a slow virtual machine is almost always explained by settings, not by the virtualization technology itself:
- the disk controller and caching mode were not chosen for the workload
- the guest system is missing guest drivers for the virtual hardware
- the virtual machine was given more CPU cores than the host physically has
- memory was handed out generously, and the host has to reclaim it through swapping
What not to do inside a container
A container should not get elevated privileges for convenience: a privileged container shares a kernel with the host with almost no barrier, and a flaw inside it threatens the whole node. Whatever needs root access to the host kernel belongs in a virtual machine, not solved through container privileges.
How to switch from one to the other if the choice was wrong
Moving usually means transferring the service's data and configuration to a new instance, not copying the container or machine itself whole, because their internal structure differs. The steps for creating a container are covered in the article on LXC containers in Proxmox.