Proxmox bietet beim Anlegen zwei Knöpfe: „Create VM“ und „Create CT“. Die Wahl beeinflusst Speicherverbrauch, Startzeit, Backup-Größe und, der entscheidende Punkt, wie gut ein Ausbruch aus dem Gast eingedämmt ist.
Der Unterschied in einem Bild#
Eine VM bekommt virtuelle Hardware und startet einen eigenen Kernel. Aus Sicht des Hosts ist sie ein einzelner Prozess, dessen Innenleben ihn nichts angeht.
Ein LXC-Container ist eine Gruppe von Prozessen auf dem Host, abgetrennt durch Namespaces und begrenzt durch cgroups. Der Kernel ist derselbe wie der des Hosts.
Was daraus folgt:
| LXC | VM | |
|---|---|---|
| Speicher im Leerlauf | wenige zehn MB | einige hundert MB |
| Startzeit | Sekundenbruchteile | Sekunden bis Minuten |
| Eigener Kernel | nein | ja |
| Kernel-Module laden | nein | ja |
| Anderes Betriebssystem | nur Linux | beliebig |
| RAM-Zuteilung | Obergrenze, ungenutztes bleibt beim Host | fest zugeteilt (ohne Ballooning) |
| Backup-Größe | klein | größer |
| Trennung bei Kernel-Lücke | schwächer | stärker |
Die Zeile mit dem RAM ist im Alltag die auffälligste: Zehn Container mit je „2 GB“ belegen zusammen so viel, wie sie tatsächlich brauchen. Zehn VMs mit je 2 GB belegen 20 GB.
Die vier Fälle, in denen die Antwort feststeht#
VM, wenn ein eigener Kernel gebraucht wird. Alles, was Kernel-Module lädt: ein eigener WireGuard-Endpunkt mit Sonderoptionen, ZFS im Gast, benutzerdefinierte Netzfilter, verschachtelte Virtualisierung.
VM, wenn es kein Linux ist. Windows, BSD, alte Appliances.
VM, wenn die Trennung entscheidend ist. Fremder Code, Kundendaten getrennt voneinander, alles, was von außen erreichbar ist und regelmäßig neue Lücken hat. Eine Kernel-Lücke betrifft alle Container auf dem Host, bei einer VM steht noch der Hypervisor dazwischen.
Container, wenn es viele gleichartige kleine Dienste sind. Ein Reverse-Proxy, ein Monitoring, ein Git-Server, ein DNS-Resolver: alles Linux, alles klein, alles vom selben Betreiber. Hier ist der Ressourcenunterschied groß und der Sicherheitsunterschied gering.
Unprivilegiert ist die Grundeinstellung#
Ein unprivilegierter Container bildet seine Benutzer-IDs auf einen hohen, unbenutzten Bereich des Hosts ab. Root im Container ist dann UID 100000 auf dem Host, jemand ohne besondere Rechte.
pct create 101 local:vztmpl/debian-13-standard_13.0-1_amd64.tar.zst \
--hostname dienst01 \
--unprivileged 1 \
--cores 2 --memory 1024 --swap 512 \
--rootfs local-lvm:8 \
--net0 name=eth0,bridge=vmbr0,ip=10.10.10.101/24,gw=10.10.10.1 \
--features nesting=1In einem privilegierten Container ist Root im Container Root auf dem Host, sobald ein Ausbruch gelingt. Es gibt Gründe dafür (bestimmte Bind-Mounts, einzelne Altlasten), aber sie sollten benannt und dokumentiert sein. „Ging sonst nicht“ ist kein Grund, meistens fehlt nur ein idmap-Eintrag.
Docker im Container: geht, mit einer Einschränkung#
Docker in einem unprivilegierten LXC läuft, wenn nesting aktiv ist und der Storage-Treiber passt:
pct set 101 --features nesting=1,keyctl=1Im Container dann Docker installieren wie gewohnt. Der Standardtreiber overlay2 funktioniert auf ZFS-Backend nicht immer sauber; in dem Fall hilft fuse-overlayfs oder eine dedizierte Platte für /var/lib/docker.
Meine Empfehlung trotzdem: Wenn viel Docker läuft, eine VM. Nicht wegen Machbarkeit, sondern weil die Fehlersuche in der Kombination LXC + Docker + Storage-Treiber schnell in Bereiche führt, in denen man lange sucht und weil Docker seine eigenen Netzregeln mitbringt, die im Container zusätzlich mit den Host-Regeln kollidieren. Mehr dazu in Docker im echten Betrieb.
Bind-Mounts: der praktische Grund für Container#
Ein Verzeichnis vom Host in den Container reichen, ohne Netzdateisystem:
pct set 101 --mp0 /tank/daten,mp=/datenBei unprivilegierten Containern muss die Zuordnung der Benutzer-IDs stimmen, sonst gehören die Dateien im Container nobody:
# /etc/pve/lxc/101.conf — UID/GID 1000 im Container auf 1000 im Host abbilden
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
Zusätzlich muss die Zeile root:1000:1 in /etc/subuid und /etc/subgid auf dem Host stehen, sonst startet der Container nicht.
Das ist fummelig und trotzdem der Grund, warum ein Dateiserver oft ein Container ist: Die Daten liegen direkt auf dem ZFS-Pool des Hosts, ohne Umweg über eine virtuelle Platte.
Ressourcen zuteilen#
# Nachträglich ändern, bei Containern meist ohne Neustart
pct set 101 --memory 2048 --cores 4
# CPU-Anteil relativ zu anderen Gästen (Standard 1024)
pct set 101 --cpuunits 512
# Harte Obergrenze: maximal 2 Kerne Rechenzeit
pct set 101 --cpulimit 2cpuunits wirkt nur unter Last und verteilt dann relativ. cpulimit deckelt hart, auch wenn der Host langweilt. Für einen Dienst, der gelegentlich Lastspitzen hat, ist cpuunits besser, er darf sich dann bedienen, wenn nichts anderes ansteht.
Was das für Backups heißt#
Container-Backups sind kleiner und schneller, weil kein Kernel und keine virtuelle Platte mitgesichert werden. Beim Wiederherstellen unterscheiden sie sich in einem Punkt: Ein Container-Backup lässt sich mit pct restore auch auf einem Host mit anderem Storage einspielen, ohne Rücksicht auf Plattenformate.
vzdump 101 --storage pbs-store1 --mode snapshot
pct restore 999 pbs-store1:backup/ct/101/2026-06-08T02:00:00Z --storage local-lvmDer snapshot-Modus setzt einen Storage voraus, der Snapshots kann (ZFS, LVM-Thin). Sonst fällt Proxmox auf suspend zurück, der Gast steht dann für die Dauer der Sicherung.
Die kurze Regel#
Linux, klein, von dir selbst betrieben → Container. Fremd, exponiert, braucht eigenen Kernel → VM.
Und im Zweifel: VM. Der Ressourcenunterschied fällt bei drei Gästen nicht auf, der Trennungsunterschied im Ernstfall schon.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Proxmox- Hosts, einen Backup-Server und Kundendienste in der EU. Fehler in einer Anleitung sind Fehler im eigenen Betrieb. Korrekturen bitte über Discord.
