> ## Content Index > Fetch the complete content index at: https://sakis.tech/llms.txt > Use this file to discover other available public pages before exploring further. # Proxmox LXC vs VM: Was wann ins Homelab gehört - URL: https://sakis.tech/proxmox-lxc-vs-vm/ - Published: 2026-09-13T08:44:33.000Z - Updated: 2026-09-13T08:44:33.000Z - Description: LXC oder VM? Auf Proxmox stellt sich die Frage spätestens beim zweiten Dienst. Was der geteilte Kernel wirklich bedeutet, wo Docker hingehört und welcher Dienst in welchen Kasten kommt: eine Liste von Fällen statt einer Glaubensfrage. - Author: Sakis - Tags: homelab, linux, docker „Unser Ziel war es immer, die Vorteile einer VM zu bieten, ohne den zusätzlichen Aufwand.“ So eröffnet die Proxmox-Doku ihr Kapitel über Container; im Original heißt es „the benefits of using a VM, but without the additional overhead“. Ein paar Sätze weiter, wo es um Anwendungs-Container geht, also um das, was Docker-Nutzer meinen, steht im selben Kapitel: Wer maximale Abschottung braucht oder laufende Gäste zwischen zwei Servern verschieben will, für den bleibe die VM die empfohlene Praxis. Beide Sätze stimmen. Und genau deshalb steht jeder, der auf Proxmox den zweiten Dienst anlegt, vor derselben Frage: Container oder virtuelle Maschine? Die Antwort ist eine Liste von Fällen. Am Ende dieses Beitrags kennst du die Liste, und du weißt, warum sie so aussieht. **Kurz gesagt:** Ein LXC-Container teilt sich den Kernel mit Proxmox, startet in Sekunden und belegt nur den Speicher, den seine Programme gerade brauchen. Eine VM ist ein kompletter Rechner in Software, mit eigenem Kernel und eigenem Bootvorgang. Daraus folgt die Faustregel: LXC für Linux-Dienste mit eigenem Installer, die im Heimnetz bleiben (Pi-hole, AdGuard Home, Unbound, ein Nginx). VM für alles, was kein Linux ist oder als fertiges System-Image kommt (Windows, Home Assistant OS, TrueNAS), für Docker und für alles, was aus dem Internet erreichbar sein soll. Stufe: Einsteiger. Stand: Proxmox VE 9.2, geprüft am 13-09-2026. ![Vergleich LXC-Container gegen virtuelle Maschine auf Proxmox: nur Linux gegen jedes System, geteilter Kernel gegen eigener Kernel, RAM nach Bedarf gegen RAM wie eingestellt, iGPU teilbar gegen Hardware exklusiv](https://sakis.tech/content/images/2026/09/grafik-20.png) Vier Unterschiede, die im Alltag entscheiden: Betriebssystem, Kernel, Arbeitsspeicher, Hardware. ## Ein Rechner in Software gegen eine Abteilung im Kernel Eine virtuelle Maschine ist genau das, was der Name verspricht. QEMU, die Software dahinter, „emuliert einen physischen Computer“, so die Proxmox-Doku: eine virtuelle Festplatte, eine virtuelle Netzwerkkarte, ein BIOS, und darauf bootet ein Betriebssystem, das von alldem nichts weiß. Die Doku nennt das „unmodified“: Windows, Debian, FreeBSD, jedes System läuft so, wie es auf echter Hardware laufen würde. Damit das schnell genug läuft, hilft KVM. Der Prozessor bringt eingebaute Virtualisierungs-Erweiterungen mit, und über das KVM-Modul im Linux-Kernel rechnet die VM fast direkt auf der CPU statt in einer Nachbildung davon. Ein LXC-Container hat von alldem nichts. Er nutzt „den Kernel des Host-Systems, statt ein komplettes Betriebssystem zu emulieren“, wieder die Doku. Was er hat, ist eine abgetrennte Sicht auf diesen Kernel: eigene Prozessliste, eigene Netzwerkschnittstelle, eigenes Dateisystem, eigener Root-Benutzer. Die Trennung besorgen Kernel-Funktionen, die die Doku beim Namen nennt: Namespaces für die getrennten Sichten, cgroups für die Grenzen bei CPU und Arbeitsspeicher, AppArmor und seccomp als Regelwerk, welche Systemaufrufe erlaubt sind. Die Laufzeitkosten dafür nennt Proxmox „niedrig, üblicherweise vernachlässigbar“. **Kernel?** Der Kern des Betriebssystems: das eine Programm, das mit der Hardware spricht, den Prozessen Rechenzeit zuteilt und entscheidet, wer welche Datei öffnen darf. Alles andere, von der Shell bis zu Pi-hole, ruft beim Kernel an. Proxmox selbst ist ein Debian mit eigenem Kernel, und genau diesen einen Kernel teilen sich alle Container auf dem Server. Ein Bild dafür: Eine VM bringt ihre eigene Küche mit, Herd, Leitungen, Sicherungskasten. Sie muss morgens erst alles hochfahren, und der Platz für die Küche ist belegt, ob gerade gekocht wird oder nicht. Ein LXC ist eine eigene Arbeitsfläche in der Küche des Hosts: eigene Messer, eigenes Kühlschrankfach, eigene Tür, aber Herd und Leitungen sind die des Hauses. Deshalb ist er sofort da und braucht nur so viel Platz, wie gerade gekocht wird. Und deshalb betrifft ein Problem am Herd alle, die daran stehen. Aus dem gemeinsamen Kernel folgt die erste harte Grenze, und die Doku formuliert sie ohne Umweg: „Only Linux distributions can be run in Proxmox Containers. It is not possible to run other operating systems like, for example, FreeBSD or Microsoft Windows inside a container.“ Windows braucht seinen eigenen Kernel, also eine VM. Dasselbe gilt für alles, was als fertiges Betriebssystem-Image kommt und seinen Kernel mitbringt. ## Was das im Alltag ausmacht Die Technik dahinter musst du nicht lieben, aber ihre Folgen begegnen dir bei jedem Klick in Proxmox. Sieben davon entscheiden die Frage in der Praxis: | | LXC-Container | Virtuelle Maschine | | --------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------- | | **Betriebssystem** | nur Linux (Debian, Ubuntu, Alpine …) | jedes: Linux, Windows, BSD, fertige Images wie Home Assistant OS | | **Start** | Sekunden, es bootet kein Kernel | bootet wie ein PC, mit BIOS und Kernel | | **Arbeitsspeicher** | eine Obergrenze; belegt wird nur, was die Programme brauchen | reserviert, was du einstellst; Ballooning kann nachregeln | | **Abschottung** | geteilter Kernel; unprivilegiert laut LXC-Team „safe by design“ | eigener Kernel; laut Proxmox „better isolation“ | | **Hardware** | Gerätedateien durchreichen, eine iGPU können sich mehrere Container teilen | PCI-Passthrough: das Gerät gehört dann dieser einen VM | | **Backup (Snapshot-Modus)** | wird kurz angehalten | läuft während der Sicherung weiter | | **Umzug im Cluster** | nur mit Neustart | live, solange kein Gerät durchgereicht ist | **Arbeitsspeicher und Start.** Bei einer VM gilt laut Doku: Stellst du Speicher und Mindestspeicher auf denselben Wert, „weist Proxmox VE der VM einfach zu, was du angibst“. Vier Gigabyte für die VM sind vier Gigabyte weniger für den Rest, auch wenn im Gast gerade nur ein Cronjob wartet. Ballooning lockert das, indem der Host der VM Speicher zwischen Minimum und Maximum zuteilt, solange er selbst genug hat. Ein Container kennt nur eine Obergrenze, gesetzt über den cgroup-Speichercontroller, und belegt darunter, was seine Prozesse tatsächlich anfassen. Pi-hole mit 512 MB Grenze belegt im Leerlauf einen Bruchteil davon. Der Start ist die gleiche Geschichte: Kein BIOS, kein Kernel, kein Init-Prozess, der Hardware sucht. Der Container ist da, sobald seine Prozesse laufen. **Abschottung.** Die Doku ist hier so klar, wie man es sich wünscht: „Containers use the kernel of the host system. This exposes an attack surface for malicious users.“ Und einen Satz später: „In general, full virtual machines provide better isolation.“ Das liest sich dramatischer, als es im Heimnetz ist. Ein unprivilegierter Container, und das ist seit Jahren die Vorgabe beim Anlegen, bildet seinen Root-Benutzer außerhalb auf einen Benutzer ohne Rechte ab. Das LXC-Team hält diese Container „safe by design“. Der privilegierte Container dagegen, bei dem Root im Container auch Root auf dem Host ist, gilt demselben Team als „unsafe“, und Ausbrüche daraus behandelt es nicht einmal als Sicherheitslücke. Wenn dich ein Assistent oder ein Skript zum privilegierten Container überreden will, ist das der Moment, kurz innezuhalten. **Unprivilegiert?** Der Root-Benutzer im Container ist außerhalb des Containers ein gewöhnlicher Benutzer mit einer hohen Nummer; Proxmox vergibt sie ab 100000\. Innen darf er alles, was Root darf, auf dem Host darf er nichts. Ein Generalschlüssel, der nur in einer Abteilung passt. Der Preis dafür steht weiter unten bei den Stolpersteinen: Dateien, die von außen hereingereicht werden, gehören plötzlich einer Nummer, die niemand kennt. **Hardware.** Das ist der Punkt, an dem der Container einen echten Vorteil hat, und den übersehen viele. Eine VM bekommt ein Gerät nur per PCI-Passthrough, und die Doku sagt dazu: Reichst du ein Gerät an eine VM durch, „kannst du dieses Gerät nicht mehr auf dem Host oder in einer anderen VM nutzen“. Die integrierte Grafik deines Mini-PCs gehört dann Jellyfin, und sonst niemandem. Ein Container bekommt stattdessen die Gerätedatei durchgereicht, in der Konfiguration heißt die Option `dev0`, in der Oberfläche steht sie seit Proxmox 8.2 unter **Resources → Add → Device Passthrough**. Der Kernel bleibt der Besitzer des Geräts, und deshalb können zwei Container dieselbe iGPU nutzen, einer zum Transkodieren, einer für die Bilderkennung. **Backup und Umzug.** Beide bekommen im Standardmodus ein Snapshot-Backup. Der Unterschied steht in der Backup-Doku: Bei der VM ist das eine Live-Sicherung, „bei der Datenblöcke kopiert werden, während die VM läuft“. Beim Container „wird der Container zuerst angehalten, um Datenkonsistenz sicherzustellen“, dann wird der Snapshot gezogen und der Container weckt wieder auf. Im Homelab merkst du davon meist nichts, es sind Sekunden. Bei mehreren Proxmox-Servern wird der Unterschied größer: „Laufende Container können aus technischen Gründen nicht live migriert werden“, heißt es in der Doku, nur mit Neustart auf dem anderen Server. Eine VM zieht bei laufendem Betrieb um, solange sie kein durchgereichtes Gerät hat. Wer einen einzelnen Server betreibt, kann diesen Punkt getrost überlesen. ## Wann ein LXC die richtige Wahl ist Der Container ist die Vorgabe für alles, was ein normales Debian oder Ubuntu ist, einen eigenen Installer mitbringt und im Heimnetz bleibt. Pi-hole ist das Musterbeispiel, [die Anleitung dazu](https://sakis.tech/pi-hole-proxmox-lxc-installieren/) steht hier. AdGuard Home, Unbound, ein schlichter Nginx, ein Samba-Server, ein Wiki, ein Git-Server: alles Dienste, die auf einem gewöhnlichen Linux zu Hause sind und weder Windows noch eigene Kernel-Module brauchen. Für jeden davon eine VM mit eigenem Kernel und eigenem Bootvorgang aufzusetzen, ist Aufwand ohne Gegenwert. Zwei Häkchen gehören dazu. Erstens bleibt der Container unprivilegiert; das ist die Vorgabe des Assistenten und der Kommandozeile, „for creation, the default is 1“, sagt die Referenz. Zweitens braucht fast jeder moderne Dienst **Nesting**, obwohl er gar keine Container in Container starten will. Die Erklärung steht in der Beschreibung der Option: „This is also required by systemd to isolate services.“ Systemd schottet Dienste mit eigenen Dateisystem-Sichten ab, und ein unprivilegierter Container darf solche Sichten nur mit Nesting anlegen. Ohne das Häkchen installiert Pi-hole fehlerfrei, und dann startet sein DNS-Dienst nicht. Im Assistenten steht das Häkchen auf dem ersten Reiter, bei einem laufenden Container unter **Options → Features**. Ich würde es prüfen statt vermuten, egal ob Assistent oder Skript den Container angelegt hat. Und Netzfreigaben? Ein unprivilegierter Container darf kein NFS und kein SMB selbst einhängen. Die Doku begründet das drastisch: Eine Option, die das erlaubt, kann dazu führen, dass „ein NFS-Dateisystem die Ein-/Ausgabe des Hosts komplett blockiert und ihn am Neustart hindert“. Der saubere Weg ist deshalb, die Freigabe auf dem Proxmox-Host einzuhängen und dem Container als Bind Mount hereinzureichen, also als Ordner, den beide sehen. ## Wann es eine VM sein muss Der erste Fall ist der einfachste: alles, was kein Linux ist. Windows für das eine Programm, das es nur dort gibt. FreeBSD, wenn du OPNsense als virtuelle Firewall probieren willst. Der zweite Fall sind Systeme, die als fertiges Image kommen und ihren eigenen Kernel mitbringen. Home Assistant OS ist das bekannteste: Das Projekt bietet für KVM und Proxmox eine qcow2-Datei an, also eine virtuelle Festplatte, die du als VM importierst; die Doku nennt 2 GB RAM und 2 Kerne als Minimum. TrueNAS und OpenMediaVault wollen als Speichersystem außerdem echte Platten für sich, und das geht nur per Passthrough an eine VM. Der dritte Fall ist die Abschottung. Ein Dienst, der aus dem Internet erreichbar ist, bekommt bei mir eine VM, weil zwischen ihm und dem Proxmox-Kernel dann ein zweiter Kernel steht. Die Doku rät zur VM, wenn Container „unbekannten oder nicht vertrauenswürdigen Personen“ zur Verfügung stehen; eine Nextcloud mit Freigabe im Router ist für mich genau das. Den eigenen Nutzern traue ich; ich weiß nur nicht, wer sonst noch klopft. Wenn ich die Sicherheitshinweise richtig lese, ist das eine Abwägung und keine Vorschrift, und ich wäge so. Der vierte Fall ist Docker, und der verdient einen eigenen Abschnitt. ## Die Docker-Frage Die meisten Anleitungen hier bauen auf Docker Compose: Vaultwarden, Uptime Kuma, Paperless-ngx, Immich, der [Nginx Proxy Manager](https://sakis.tech/was-ist-ein-reverse-proxy-einfach-erklart-furs-homelab/). Docker ist selbst ein Container-System und braucht dieselben Kernel-Funktionen wie LXC: Namespaces, cgroups, AppArmor. Docker in einem LXC heißt also: Container in einem Container, beide mit Wünschen an denselben Kernel. Dass das prinzipiell geht, sieht man an der Container-Referenz von Proxmox, die für die Option `keyctl` schreibt, sie sei „nötig, um Docker in einem Container zu benutzen“. Dass es hakelig ist, steht ein paar Sätze weiter in derselben Referenz: „Im Grunde kannst du wählen, ob du systemd-networkd oder Docker laufen lässt.“ Ein Satz, der in einer Referenz steht und nach einer Kapitulation klingt. Was Proxmox empfiehlt, steht im Container-Kapitel, das ich am Anfang zitiert habe: Für maximale Abschottung und Live-Migration bleibt die VM die empfohlene Praxis. Im Proxmox-Forum sagen es die erfahrenen Mitglieder deutlicher. „Don't use docker inside an lxc, this isn't really supported and might break at any time (especially due to updates)“, schreibt Johannes S. im Oktober 2024\. Und die Updates kamen: Im Juli 2025, mit der Beta von Proxmox 9.0, blieben Docker-Container in LXCs mit „permission denied“ beim Einhängen von `/dev/mqueue` stehen; Ursache war ein geändertes AppArmor-Profil, ein Proxmox-Mitarbeiter bestätigte das im Thread, und die Abhilfe hieß erst einmal Container-Distribution aktualisieren oder AppArmor für den Container abschalten. Im Juli 2026 fragte jemand im selben Forum, ob Docker und LXC inzwischen zuverlässig zusammenarbeiten. Die Antwort von Impact: Es funktioniere, könne aber „bei Docker- oder Kernel-Updates brechen“; fürs Homelab vertretbar, für alles Wichtige eine VM. Warum machen es dann so viele? Zwei Gründe, und beide sind gut. Der eine ist die iGPU aus dem Hardware-Absatz: Jellyfin als Docker-Container im LXC bekommt die Grafikeinheit durchgereicht und teilt sie sich mit anderen, in einer VM gehört sie ihm allein oder gar nicht. Der andere ist Bequemlichkeit: Die Helper-Scripts der Proxmox-Community, ein Projekt mit über 29.000 Sternen auf GitHub, legen mit einem Befehl einen unprivilegierten Debian-13-Container mit Docker an, zwei Kerne, zwei Gigabyte, vier Gigabyte Platte. Das ist in einer Minute fertig und läuft. Das Skript selbst ist nicht mein Problem. Die Zeile davor schon: `curl … | bash` als Installationsweg auf dem Rechner, der alle anderen trägt. Johannes S. sagt im Forum dasselbe, und ich sehe es wie er. Und dann ist da noch die neue Tür, die Proxmox selbst aufgemacht hat. Seit Version 9.1 vom 19-11-2025 kann Proxmox einen LXC-Container direkt aus einem OCI-Image anlegen, also aus dem Format, in dem Docker-Images verpackt sind. Ein Image aus dem Docker Hub, von Proxmox beim Anlegen auf den LXC-Unterbau umgebaut, mit Umgebungsvariablen in den Container-Optionen. Kein Docker, kein Container im Container, der Dienst läuft unmittelbar auf dem Host-Kernel. Ich finde das die interessanteste Entwicklung an Proxmox seit Jahren. Und trotzdem würde ich noch nichts darauf bauen, aus zwei Gründen. Die Doku nennt es an drei Stellen „technology preview“, und Vorschau heißt Vorschau. Und Johannes S. legt im Forum den Finger auf den wunden Punkt: Die Umwandlung „zerstört die Unveränderlichkeit, die der größte Vorteil von Docker gegenüber LXCs ist“. Ein Docker-Container wird bei jedem Update weggeworfen und aus dem neuen Image neu gebaut; ein LXC ist ein Dateisystem, in dem Änderungen liegen bleiben. Was ein Update dann bedeutet, ist noch nicht ausbuchstabiert. **OCI-Image?** Das Verpackungsformat für Docker-Images, festgelegt von der Open Container Initiative, damit nicht jeder Hersteller sein eigenes kocht. Ein Image ist ein fertiges Dateisystem mit Programm und Startbefehl. Docker Hub ist der größte Katalog davon, und genau dort kann Proxmox seit 9.1 einkaufen. Ich würde für Docker eine VM nehmen, und die Gründe dafür stehen oben zum Nachprüfen. Ein Debian, Docker drauf, alle Compose-Stapel hinein, fertig. Das kostet einen zweiten Kernel im Speicher und ein paar Sekunden mehr beim Start, und dafür überstehen deine Dienste das nächste große Proxmox-Update, ohne dass du morgens im Forum nach AppArmor suchst. Docker im LXC nur mit gutem Grund, und der einzige, der mir einleuchtet, ist die geteilte iGPU. Wer den Weg geht, macht vor jedem Proxmox-Sprung ein Backup des Containers und liest die Release Notes. Ja, das ist der Backup-Satz. Er steht hier, weil der Fall von 2025 genau so aussah. ## Was ich wohin stecken würde Die Liste für ein typisches Homelab, das aus den Anleitungen hier zusammengewachsen ist: - **Pi-hole, Unbound, AdGuard Home:** je ein unprivilegierter LXC mit Nesting. Klein, schnell, und der DNS-Server muss laufen, bevor alles andere hochkommt. - **Nginx Proxy Manager, Vaultwarden, Uptime Kuma, Paperless-ngx, Immich, Backrest:** eine gemeinsame Docker-VM. Ein Debian, ein Docker, ein Ordner pro Dienst. Immich und Paperless sind mit ihren Datenbanken auch die, bei denen ich am wenigsten Lust auf Kernel-Überraschungen habe. - **Jellyfin:** LXC, wenn die iGPU transkodieren soll. Jellyfin bringt ein eigenes Debian-Paket mit, Docker ist dafür nicht nötig, und die Gerätedatei der Grafikeinheit kommt per Device Passthrough herein. Ohne Transkodierung passt es auch in die Docker-VM. - **Home Assistant OS:** VM, aus der qcow2-Datei des Projekts. - **Windows, OPNsense, TrueNAS:** VM, ohne Diskussion. - **Alles mit Freigabe im Router:** VM, siehe oben. Wer sich das ansieht, merkt: Am Ende sind es zwei, drei Container und zwei, drei VMs. Nicht dreißig Gäste, nicht einer. Die Kunst besteht darin, jedem Dienst die passende Technik zu geben, statt sich pauschal für eine zu entscheiden. ## Wo es klemmt **Ein Dienst im LXC installiert fehlerfrei und startet dann nicht.** Bei Pi-hole steht im Status `status=226/NAMESPACE`, bei anderen systemd-Diensten etwas Ähnliches. Das ist der Container ohne Nesting; im Pi-hole-Forum ist der Fall seit 2023 dokumentiert, die Lösung ist das Häkchen unter **Options → Features**. Nachträglich setzen, Container neu starten, fertig. **Hereingereichte Ordner gehören einer Nummer, nicht dir.** Ein Bind Mount aus dem Host in einen unprivilegierten Container zeigt Dateien, die dem Benutzer 100000 oder einer noch höheren Nummer gehören, und der Dienst im Container darf nicht schreiben. Die Doku warnt genau davor: „With unprivileged containers you might run into permission problems caused by the user mapping and cannot use ACLs.“ Die Ursache ist die Abbildung aus dem Klartext-Kasten oben: Benutzer 1000 im Container ist auf dem Host Benutzer 101000\. Entweder du gibst den Ordner auf dem Host dieser Nummer, oder du nimmst für diesen einen Dienst die Docker-VM, in der das Thema nicht existiert. **NFS oder SMB im Container schlägt fehl.** „Operation not permitted“ oder eine Meldung über fehlende Rechte beim `mount`. Der Container darf das nicht, siehe oben; einhängen auf dem Host, hereinreichen als Bind Mount. Wer stattdessen den Container privilegiert macht, hat das Problem gelöst und ein größeres gekauft. **Docker im LXC ist nach einem Proxmox-Update kaputt.** Container starten nicht mehr, in den Meldungen steht „permission denied“ oder AppArmor. Das ist das Muster vom Juli 2025\. Der Thread im Proxmox-Forum nennt die Abhilfen; ehrlicher ist, den Fall als das zu nehmen, was er ist: die Rechnung für den Container im Container. **Die VM ist langsam oder hängt beim Backup.** Zwei Dinge, die beim Anlegen einer VM gern übersprungen werden. Die Festplatte und die Netzwerkkarte gehören auf **VirtIO**; die Proxmox-Doku hat es gemessen: doppelter sequenzieller Schreibdurchsatz gegenüber dem emulierten IDE-Controller, bis zu dreifacher Netzwerkdurchsatz gegenüber der emulierten Intel-E1000-Karte. Und der **QEMU Guest Agent**, ein kleines Programm im Gast, „das einen Kommunikationskanal zwischen Host und Gast bereitstellt“: Ohne ihn weiß Proxmox nicht, wann die VM sauber heruntergefahren ist, und kann ihr vor dem Backup nicht sagen, dass sie ihre Dateien kurz zur Ruhe bringen soll. Einmal eingerichtet, und die VM benimmt sich wie ein Gast, der Bescheid sagt. Der Satz aus der Doku, mit dem das hier anfing, hat also einen Nachsatz verdient: Die Vorteile einer VM ohne den Aufwand gibt es wirklich, für alles, was ein gewöhnliches Linux ist. Für den Rest gibt es die VM, und ihr Aufwand ist der Preis für den zweiten Kernel. Wie sieht es bei dir aus: Läuft dein Docker im LXC, in einer VM, oder direkt auf dem Proxmox-Host, weil es irgendwann einfach so passiert ist? Und hat dich ein Proxmox-Update schon einmal erwischt? Schreib es in die Kommentare, ich sammle die Fälle. Wenn der erste Container bei dir Pi-hole wird, führt [die LXC-Anleitung](https://sakis.tech/pi-hole-proxmox-lxc-installieren/) Schritt für Schritt durch den Assistenten, inklusive der beiden Häkchen aus diesem Beitrag. sakis@homelab:\~$ echo "bleib neugierig — und mach backups" ## Quellen - [Proxmox VE Admin Guide: Proxmox Container Toolkit (Einleitung, Technology Overview, OCI-Images als Technology Preview, Security Considerations, unprivilegierte und privilegierte Container, Bind Mounts, Migration)](https://pve.proxmox.com/pve-docs/chapter-pct.html?ref=sakis.tech) - [Proxmox VE Admin Guide: QEMU/KVM Virtual Machines (Emulation, unmodified operating systems, VirtIO-Messwerte, Memory und Ballooning, Guest Agent, Live-Migration)](https://pve.proxmox.com/pve-docs/chapter-qm.html?ref=sakis.tech) - [Proxmox VE: pct.conf(5) (Optionen features mit keyctl, nesting, mount; dev\[n\]; unprivileged)](https://pve.proxmox.com/pve-docs/pct.conf.5.html?ref=sakis.tech) - [Proxmox VE Admin Guide: Backup and Restore (Backup-Modi für VMs und Container)](https://pve.proxmox.com/pve-docs/chapter-vzdump.html?ref=sakis.tech) - [Proxmox VE Admin Guide: PCI(e) Passthrough (Gerät steht Host und anderen VMs nicht mehr zur Verfügung)](https://pve.proxmox.com/pve-docs/chapter-qm-pci-passthrough.html?ref=sakis.tech) - [Proxmox: Pressemitteilung zu Proxmox VE 8.2 (Device Passthrough für Container in der Oberfläche, 24-04-2024)](https://www.proxmox.com/en/about/press-releases/proxmox-virtual-environment-8-2?ref=sakis.tech) - [Proxmox VE: Roadmap und Release Notes (9.1 vom 19-11-2025 mit OCI-Images, 9.2 vom 21-05-2026)](https://pve.proxmox.com/wiki/Roadmap?ref=sakis.tech) - [Proxmox-Forum: Docker in Unpriviledged LXC or Dedicated VM? (Oktober 2024, Johannes S. und LnxBil)](https://forum.proxmox.com/threads/docker-in-unpriviledged-lxc-or-dedicated-vm.156369/?ref=sakis.tech) - [Proxmox-Forum: Proxmox VE 9.0 BETA LXC Docker not working (Juli 2025, AppArmor und /dev/mqueue)](https://forum.proxmox.com/threads/proxmox-ve-9-0-beta-lcx-docker-not-working.168626/?ref=sakis.tech) - [Proxmox-Forum: LXC and Docker compatibility now (Juli 2026, Impact und Johannes S. zur OCI-Umwandlung)](https://forum.proxmox.com/threads/lxc-and-docker-compatibility-now.185224/?ref=sakis.tech) - [Proxmox VE Helper-Scripts: docker.sh (unprivilegierter Debian-13-Container, Vorgaben für Kerne, RAM und Platte)](https://github.com/community-scripts/ProxmoxVE/blob/main/ct/docker.sh?ref=sakis.tech) - [Home Assistant: Installation auf einem Hypervisor (qcow2 für KVM/Proxmox, Mindestanforderungen)](https://www.home-assistant.io/installation/alternative/?ref=sakis.tech)