Proxmox VM czy LXC — kiedy co wybrać
Proxmox hostuje 12 maszyn u mnie — mix VM i LXC. Pokazuję regułę kiedy używać kontenerów Linux, a kiedy pełnej wirtualizacji, na konkretnych przykładach.
Proxmox VE oferuje dwa typy izolacji: pełne VM i Linux containers (LXC). Większość ludzi korzysta tylko z VM, bo są "bezpieczniejsze". Ja mam ~60% LXC, ~40% VM. Pokazuję regułę kiedy co wybrać.
Krótka charakterystyka
| VM | LXC | |
|---|---|---|
| Izolacja | pełna (KVM) | namespace + cgroups |
| Boot time | ~30s | ~2s |
| RAM overhead | +200-500MB | +5-20MB |
| Storage overhead | duży (qcow2) | mały (rootfs) |
| Live migration | tak | tak |
| Kernel | własny | hosta |
| Bezpieczeństwo | mocne | słabsze (CVE escapów) |
LXC to nie Docker, to "lekka VM" z własnym init, użytkownikami, plikami. Bardziej jak BSD jails niż Docker.
Reguła: kiedy LXC
LXC dla:
- Single-purpose serwisy (jeden daemon, mały stack): Pi-hole, Vikunja, single-DB
- Self-hosted apki Linux-only: Nextcloud, Jellyfin, Bitwarden
- Test environments: setup/teardown w 30s
- Cokolwiek wymagającego zaledwie kilka MB RAM idle
LXC NIE dla:
- Cokolwiek z innym kernelem niż hosta (Windows, BSD, ARM na x86 hostie)
- Workloads z exposed root (root w LXC + escape = root na hostie)
- Wszystko co musi być fully isolated dla compliance
Reguła: kiedy VM
VM dla:
- Inne OS: Windows do testów, BSD jako router (pfSense, OPNsense)
- Kernel modules: ZFS-on-Linux, eBPF probes, custom kernel
- Mocna izolacja: serwisy które potencjalnie obsługują niezaufane dane
- Hardware passthrough: GPU passthrough, USB devices
Konkretne przykłady z mojego setupu
LXC: Pi-hole
Pi-hole używa ~50MB RAM idle. VM by potrzebowała 512MB tylko na overhead. LXC = pct create 100 ubuntu-22.04 --rootfs local-zfs:8 --memory 256 i działa.
LXC: Vikunja + Postgres
Dwa LXC w jednej zone. Vikunja słucha na 3456, Postgres na 5432, komunikują się przez wewnętrzny network. Razem zużywają ~500MB RAM, VM-na-każdy by zżerała 1.5GB.
VM: pfSense
Routing musi mieć FreeBSD. Plus ja używam packageów typu Suricata które wymagają specific kernel modules. VM jest jedyną opcją.
VM: Home Assistant OS
HA OS dostarcza całą dystrybucję z pre-konfigurowanym addon systemem. Jako LXC by trzeba było składać ręcznie. VM = pobierz .qcow2 z home-assistant.io, zaimportuj, działa.
VM: Jellyfin (z GPU passthrough)
Transcoding wideo wymaga karty graficznej. Passthrough GPU do LXC jest możliwy ale wkurzający. VM to standardowy flow.
Konwersja między LXC a VM
Czasem startujesz w jednym, potem chcesz zmienić.
LXC → VM: trudne. Potrzebny migration via tarball + wirtualny format conversion. Lepiej na nowo postawić VM.
VM → LXC: prawie niemożliwe bez re-instalacji. VM ma własny kernel i bootloader, LXC dziedziczy.
Reguła: zaplanuj na samym początku. Jak nie wiesz, zacznij z LXC, łatwiej jest zwiększyć izolację (postaw VM od nowa) niż zredukować.
ZFS jako bonus
Proxmox lubi ZFS. Mam swoje containers/VMy na ZFS pool z:
- Snapshoty: instant copy state, atomicznie.
zfs snapshot pool/lxc-100@before-update - Send/receive: replikacja na drugi host w pół godziny
- Compression: ~30% mniej miejsca
ZFS w LXC działa szczególnie dobrze, bo container nie potrzebuje własnego file systemu, dziedziczy z hosta.
Pułapki
1. LXC unprivileged vs privileged. Domyślnie unprivileged (root w container = mapowany do unprivileged user na host). Bezpieczniej, ale niektóre apki nie chcą działać. Privileged = wygodniej, ale escape = full host root.
2. Backup VM jest duży. Snapshot 50GB VM = backup 50GB. LXC z tych samych danych = backup 5GB. ZFS dedup pomaga ale nie zawsze.
3. Live migration LXC. Działa, ale wymaga shared storage albo replikacji. VM jest na to lepiej dostosowany.
4. LXC kernel = host kernel. Update hosta = restart wszystkich LXC. Update VM kernel = zero downtime na hoście. Plan downtime windowse.
Liczby z mojego homelabu
- 4 VM: pfSense, HA OS, Jellyfin (GPU PT), Windows Server (ad-hoc)
- 8 LXC: Pi-hole×2, Vikunja, Postgres, Bitwarden, Nextcloud, Obsidian-sync, dev-test
- Razem zużycie: ~12GB RAM z 64GB dostępnych
- Średni boot time LXC: 1.8s, VM: 28s
LXC daje mi 8x więcej serwisów na tym samym hardware. Bez kompromisów na funkcjonalność dla większości rzeczy.
Zaczynaj od LXC. Eskaluj do VM tylko gdy masz konkretny powód (inny OS, kernel modules, izolacja, hardware). Większość self-hosted apek nie potrzebuje VM, a Twój RAM Ci za to podziękuje.