In a previous video, I did a high-level comparison of VMs, LXC, and Docker. The more specific question I want to answer today is should you run Docker in a VM or LXC and why.
So let’s look at the specific technical trade-offs in Proxmox 9.1 so you can stop guessing and start architecting.
The Decision Matrix (PVE 9.1)
| Feature | Docker in a VM | Docker in an LXC (Container) |
|---|---|---|
| Kernel Isolation | Total. Dedicated guest kernel. | None. Shares the Proxmox host kernel. |
| System Stability | Safe. VM crash is isolated. | High Risk. kernel panic can crash the host. |
| Live Migration | Full Support. Move live between nodes. | No. Requires a full stop/start cycle. |
| Network Storage | Native. Seamless NFS/SMB mounts. | Complex. Requires bind mounts or privileges. |
| GPU Passthrough | Exclusive. VM “owns” the card. | Shared. Multiple LXCs can share one GPU. |
| Resource Cost | Moderate. more RAM/CPU overhead. | Near-Zero. Scales dynamically with the host. |
1. Limiting Risk
In an LXC, you share the host kernel. This is the single biggest risk factor. If a Docker container triggers a kernel-level hang or a resource exhaustion bug, it doesn’t just stop the container, it can potentially lock up the entire Proxmox hypervisor. If you have 20 other production VMs on that node, they all go dark.
- Verdict: For production workloads put it in a VM for better isolation.
2. Networking & Storage (The NFS/SMB Challenges)
Mounting external shares inside an LXC is a notorious pain point. Because of how unprivileged containers handle User Namespaces (UID/GID mapping), getting permissions right for an NFS or SMB share can be a pain.
- The VM Advantage: A VM treats an NFS/SMB mount like a native OS operation. If your Docker stack needs to talk to external storage such as TrueNAS box or a Synology, use a VM.
3. The GPU Passthrough Trade-off
- VM (PCIe Passthrough): You pass the hardware ID to the VM. The host can no longer see it. This is the stablest method for high-performance AI or a dedicated gaming node.
- LXC (Device Mapping): The host keeps the driver and you “map” the device into the container. This allows multiple containers same GPU simultaneously.
4. ZFS Optimization: (if you are using ZFS) for VM or LXC
Tuning Record Size:
If you run a high-I/O applications such as database (MariaDB, Postgres, InfluxDB), or logging tools which write smaller commits than the Proxmox default 128K recordsize this can cause Write Amplification. To solve this issue you can set ZFS to a record size more suited for those applications:
zfs set recordsize=16k rpool/data/subvol-109-disk-0
Final Thoughts
- Choose a VM if: You prioritize absolute stability and isolation. This is the gold standard if you need to Live Migrate for host maintenance without downtime or if your stack relies heavily on external NAS storage (NFS/SMB).
- Choose an LXC if: You are resource-constrained or need to share a single GPU across multiple services (like Plex + AI tools). This is ideal for lab environments where a host reboot isn’t a catastrophe.
- Choose based on the Application: Self-contained “utility” apps, like networking tools, lightweight proxies, or small automation scripts, are good candidates for LXC. If the app doesn’t need complex external storage or high-write database tuning, the efficiency of LXC might be a good fit.