LXC vs. Docker

Noch einmal: Wofür? LXC und Docker sind beides eine Art von Container und ob da nun "wichtige" Anwendungen oder "kleinere" Anwendungen laufen spielt keine Rolle.


Vermutlich weil irgendjemand dafür mal - aus was für Gründen auch immer - einen Bedarf hatte. :) Wie bereits geschrieben: Einen Container (Docker) in einem Container (LXC) laufen zu lassen macht nicht wirklich Sinn. D.h. nicht das man das nicht machen kann, oder warum auch immer machen möchte. Docker und LXC sind halt nicht 1:1 identisch, aber es sind beides Container Varianten. Aber wie die anderen User hier ja schon erwähnt haben installiert man sich Docker üblicherweiser in einer VM und nicht in einem LXC.

D.h. die Anwendungen die Du jetzt auf der DS im Docker laufen hast kannst Du mit sehr großer Wahrscheinlichkeit dann auch in einm LXC laufen lassen. Dadurch ergibt sich zwar die ein oder andere kleine Änderung, aber auf den Betrieb der Anwendung hat das nicht wirklich eine Auswirkung. Das wäre zumindest die übliche Vorgehensweise. Wenn Du - warum auch immer - weiterhin Docker benutzen möchtest installierst Du Dir eine Linux VM als Basis und darunter dann Docker.

VG JIm
OK, verstanden. Dann also nur LXC. Dann wäre noch meine Frage wegen der Ressourcen:

4. Zum Thema Ressourcenmanagement bei Proxmox: Bei Docker brauche ich nicht dediziert einem Dienst die Ressourcen zuweisen. Alle Container unter Docker nutzen die der VM zur Verfügung gestellten Ressourcen. Beim "Ansatz 1 LXC = 1 Dienst" muss ich jedem Container die Ressourcen zuweisen.
Jetzt hat mein kleiner Proxmox Test Mini PC 32 GB Ram und eine 8-Core CPU. Für jede Maschine in Proxmox muss ich RAM und CPU genau festlegen.

Heißt das, ich kann maximal 32 GB auf die LXC und VM zuweisen? Oder kann man in Summe mehr zuweisen und der Proxmox Server verteilt die Ressourcen nach Bedarf bzw. anteilig?
 
Heißt das, ich kann maximal 32 GB auf die LXC und VM zuweisen? Oder kann man in Summe mehr zuweisen und der Proxmox Server verteilt die Ressourcen nach Bedarf bzw. anteilig?
CPUs kann man überbuchen, solange man es nicht übertreibt, RAM sollte dagegen nicht überbucht werden, weil es dann entweder extrem langsam wird ( sofern Swap vorhanden) oder der Linux-Kernel anfängt Prozesse ( also auch vms und container) abzuschießen, um RAM frei zu bekommen.

Mit zram kann man sich ( dafür steigt die CPU-Last) etwas Luft verschaffen:

https://wiki.debian.org/ZRam
 
Last edited:
CPUs kann man überbuchen, solange man es nicht übertreibt, RAM sollte dagegen nicht überbucht werden, weil es dann entweder extrem langsam wird ( sofern Swap vorhanden) oder der Linux-Kernel anfängt Prozesse ( also auch vms und gontainer) abzuschießen, um RAM frei zu bekommen.

Mit zram kann man sich ( dafür steigt die CPU-Last) etwas Luft verschaffen:

https://wiki.debian.org/ZRam
Super Danke. Dann hab ich jetzt alles. Dann werde ich mal anfangen, die bestehenden Docker-Container in LXC neu aufzusetzen. Ist ja noch nicht viel ...
 
  • Like
Reactions: Johannes S
CPUs kann man überbuchen, solange man es nicht übertreibt, RAM sollte dagegen nicht überbucht werden, weil es dann entweder extrem langsam wird ( sofern Swap vorhanden) oder der Linux-Kernel anfängt Prozesse ( also auch vms und container) abzuschießen, um RAM frei zu bekommen.

Mit zram kann man sich ( dafür steigt die CPU-Last) etwas Luft verschaffen:

https://wiki.debian.org/ZRam

Jetzt muss ich doch nochmal eine Frage zur Ressourcenverwaltung LXC und Docker stellen.
Bei LXC Containern muss ich jedem Container seine Ressourcen zuweisen und sollte insbesondere den Ram nicht überbuchen. OK, verstanden.

Aber dann sehe ich aber doch einen Vorteil von Docker: Wenn ich Docker auf einer VM installieren, brauche ich nicht jedem Container einzeln die Ressourcen zuweisen. ich verstehe es so, dass Docker sich für alle Container der Ressourcen der VM nach Bedarf bedient. Da die meisten meiner Container ohnehin kaum etwas tun (Dashboard, Bitwarden, Paperless, usw.), könnte ich eine Reihe Container aufsetzen und muss nur einmal z.B. 8 GB Ram vergeben. Wenn ich alle Container einzeln als LXC aufsetzen würde, käme ich in Summe hws. auf eine höhere RAM-Zuweisung, wenn ich die empfohlenen RAM -Werte ansetze.

Verstehe ich das richtig? Hat da nicht Docker doch Vorteile?
 
  • Like
Reactions: sdettmer
Jetzt muss ich doch nochmal eine Frage zur Ressourcenverwaltung LXC und Docker stellen.
Bei LXC Containern muss ich jedem Container seine Ressourcen zuweisen und sollte insbesondere den Ram nicht überbuchen. OK, verstanden.

Aber dann sehe ich aber doch einen Vorteil von Docker: Wenn ich Docker auf einer VM installieren, brauche ich nicht jedem Container einzeln die Ressourcen zuweisen. ich verstehe es so, dass Docker sich für alle Container der Ressourcen der VM nach Bedarf bedient. Da die meisten meiner Container ohnehin kaum etwas tun (Dashboard, Bitwarden, Paperless, usw.), könnte ich eine Reihe Container aufsetzen und muss nur einmal z.B. 8 GB Ram vergeben. Wenn ich alle Container einzeln als LXC aufsetzen würde, käme ich in Summe hws. auf eine höhere RAM-Zuweisung, wenn ich die empfohlenen RAM -Werte ansetze.

Verstehe ich das richtig? Hat da nicht Docker doch Vorteile?

Docker hat in meinen Augen vor allen den Vorteil, dass es dafür vieles "fertig" gibt, so dass neue Dienste schnell aufgesetzt sind und auch leicht aktualisiert werden können. Außerdem muss dann nur das Betriebssystem von einer VM administriert, aktualisisert etc werden statt für zig Container.
Grundsätzlich sind aber LXCs (trotz der Ressourcenzuweisung) ressourcenschonender, da nicht genutzte Ressourcen von anderen Containern genutzt werden können.

Trotzdem hast du schon ganz gut beschrieben, warum (entgegen der Annahme, die oft auf reddit vertreten wird) eine Docker-VM nicht per se mehr Ressourcen frisst als Container. Grob gesagt: Wenn ich für jeden Dienst einen Container haben will, dann ist ein LXC pro Dienst natürlich ressourcenschonender als eine VM pro Dienst. Aber mit Docker macht man das ja sinnvollerweise nicht, sondern packt alle Docker-Instanzen in eine VM.
 
Last edited:
Docker hat für mich den Vorteil, dass Container Instanzen vergänglich sind und - je nach Umgebung - keine Änderungen am Filesystem zulassen. Das bedeutet:
- der Container kann jederzeit gelöscht und neu erstellt werden
- alle persistenten Informationen müssen außerhalb des Containers gespeichert werden (in einem Volume).
 
Docker hat für mich den Vorteil, dass Container Instanzen vergänglich sind und - je nach Umgebung - keine Änderungen am Filesystem zulassen. Das bedeutet:
- der Container kann jederzeit gelöscht und neu erstellt werden
- alle persistenten Informationen müssen außerhalb des Containers gespeichert werden (in einem Volume).

Jap, damit lassen sich auch schnell schiefgelaufene Updates oder Hackerangriffe/Ransomware (sofern man ein Backup der persistenten Daten von der Version vor dem Update/Angriff hat) gut wieder zurückabwickeln.
… oder in mehrere VMs und packt einen Container Orchestrator wie Kubernetes dazwischen.
Klar ;) Für die Anwendung im Heimnetz dürfte das aber ein bissel too much sein. Unter anderen deshalb ist ja ixsystems für TrueNAS Scale im jüngsten Release für Apps von Kubernetes auf docker umgestiegen. Wenn man natürlich das ganze auch als Lernchance sieht, bietet sich Kubernetes natürlich an, ich würde nur dann nichts produktiv darauf laufen lassen. Für Produktives gilt: "Keep it simple, stupid" und das ist Kubernetes bei all seinen Vorzügen halt beim besten Willen nicht.
 
Last edited:
CPUs kann man überbuchen, solange man es nicht übertreibt, RAM sollte dagegen nicht überbucht werden, weil es dann entweder extrem langsam wird ( sofern Swap vorhanden) oder der Linux-Kernel anfängt Prozesse ( also auch vms und container) abzuschießen, um RAM frei zu bekommen.

...

Sorry, ich muss das Thema nochmal ansprechen. Ich habe zwischenzeitlich ein bisschen weiter probiert:

Ich habe in meinem Mini-Test-PC einen 8-Core Prozessor. Diese 8 Kerne sind aber schnell vergeben: Ich habe LXC Container mit einem MS SQL Server, Adguard, Paperless, Bitwarden, Bookstack usw. Selbst, wenn ich jedem Container nur einen Core zuweise, ist bei spätestens 8 Containern Schluss, oder man überbucht, dann kommen vielleicht noch 2-4 Container dazu.

Wenn Du jetzt schreibst, man soll es bei der Buchung der CPU nicht übertreiben, dann frage ich mich, wie es andere machen. In manchen Tutorials sieht man Proxmox Server mit etlichen LXC Containern. Da müsste ja erheblich überbucht worden sein? Oder habe ich das falsch verstanden?
 
Ich habe in meinem Mini-Test-PC einen 8-Core Prozessor. Diese 8 Kerne sind aber schnell vergeben: Ich habe LXC Container mit einem MS SQL Server, Adguard, Paperless, Bitwarden, Bookstack usw. Selbst, wenn ich jedem Container nur einen Core zuweise, ist bei spätestens 8 Containern Schluss, oder man überbucht, dann kommen vielleicht noch 2-4 Container dazu.

Wenn Du jetzt schreibst, man soll es bei der Buchung der CPU nicht übertreiben, dann frage ich mich, wie es andere machen. In manchen Tutorials sieht man Proxmox Server mit etlichen LXC Containern. Da müsste ja erheblich überbucht worden sein? Oder habe ich das falsch verstanden?
Naja, die Frage ist ja nicht nur, wieviel CPU-Kerne du zugewiesen hast, sondern auch wieviel RAM. Außerdem würde ich Screenshots/Tutorials auch immer mit einer gewissen Skepsis betrachten, nur weil da jemand mal einen Screen von gemacht hat, heißt das nicht, dass er oder sie das so dauerhaft betreibt ;)

Auch mit Containern macht man aus einen Käfer keinen Ferrari und auch ein Ferrari kann nicht die Gesetze der Physik wiederlegen ;)
Der MS SQL Server wird ja kein Container, sondern eine VM sein, oder? Schaue bitte noch einmal, wieviele VMs bzw. Container du konkret hast und wieviel RAM bzw. CPU Kerne zugewiesen sind.
 
  • Like
Reactions: PVE-Newbee
OK, also hier mal meine Testumgebung auf einem Mini-PC. Es ist erstmal nur zum Testen, ob es auch alles so klappt, wie ich mir das denke. Produktiv läuft hier noch gar nichts. Am Ende soll bei erfolgreichem Test ein neuer Server in einen 19 Zoll Schrank:

Hardware: Intel I5-12450H (8C/12T), 32 GB Ram, 1 TB M2.NVME

Hier die aktuellen Installationen mit Ressourcenzuordnung:

Typ / Zweck / Core / Ram / HDD
LXC / adguard / 1 / 512 MB / 2 GB
LXC / MS SQL Server / 4 / 8 GB / 64 GB
LXC / Dashboard / 2 / 1 GB / 3 GB
LXC / NGINX / 2 / 1 GB / 4 GB
LXC / PaperlessNGX / 2 / 8 GB / 30 GB
LXC / homebox / 1 / 1 GB / 10 GB
VM / ubuntu mit Docker / 4 / 8 GB / 128 GB

SUMME: 16 Core (von 8, also überbucht) / 27,5 GB (von 32 GB) / ca 250 Gb (von 1 TB)

Bitwarden, Jellyfin und Bookstack fehlen noch.

Ist alles noch im Test. Ich habe die VM mit Docker parallel aufgesetzt. Die Werte für die Ressourcen habe ich meistens aus Vorschlägen der Doku, außer bei Paperless, da bin ich beim RAM höher gegangen aus der Erfahrung.
Die meisten Container tun ja die meiste Zeit nichts, insbesondere die mit viel Ressourcenzuordnung wie Paperless sind die meiste Zeit arbeitslos. Daher meine Frage, ob da nicht Docker besser wäre. Vom reinen Handling her ist mir LXC lieber als Docker.

Im Moment teste ich halt beides: LXC und Docker. Ob der SQL Server als LXC oder VM läuft, muss ich noch schauen. Vielleicht ist eine VM ratsamer.

Ich frage mich mittlerweile auch schon, ob ich mit Proxmox die richtige Wahl getroffen habe, weil es ja eine Virtualisierungsumgebung ist und ob z.B. Unraid am Ende geeigneter wäre für meine Anforderung (ich hatte Unraid auch schon probiert, gefällt mir vom Handling aber überhaupt nicht).

Oder sind die Dienste am Ende dann doch zu viel für einen Server und ich brauche einen zweiten?

Fragen über Fragen ...
 
Typ / Zweck / Core / Ram / HDD
LXC / adguard / 1 / 512 MB / 2 GB
LXC / MS SQL Server / 4 / 8 GB / 64 GB

MS SQL Server oder Mysql? Mir ist neu, dass der MS SQL Server auch unter Linux läuft ;)

LXC / Dashboard / 2 / 1 GB / 3 GB
LXC / NGINX / 2 / 1 GB / 4 GB
LXC / PaperlessNGX / 2 / 8 GB / 30 GB
LXC / homebox / 1 / 1 GB / 10 GB
VM / ubuntu mit Docker / 4 / 8 GB / 128 GB

Nun ja, wir kommen also auf 16 zugeordnete Cores und der Host braucht ja auch noch ein wenig. Hast du ein Monitoring, wie die CPU Auslastung bei den einzelnen LXCs ist? Wenn (Extrembeispiel) alle LXCs + VMs ständig bei 100% Auslastung sind, dann wäre es kein Wunder, dass es zu Problemen kommt. Die Idee hinter der Überbuchung ist darauf zu wetten, dass nie alle LXcs/VMs gleich stark ausgelastet sind, bzw. wenn sie es sind, die resultierende Performance immer noch erträglich ist.


Die meisten Container tun ja die meiste Zeit nichts, insbesondere die mit viel Ressourcenzuordnung wie Paperless sind die meiste Zeit arbeitslos. Daher meine Frage, ob da nicht Docker besser wäre. Vom reinen Handling her ist mir LXC lieber als Docker.

Ist im Endeffekt Geschmacksache, bei Jellyfin ist zu bedenken, dass Lxc besser ist, wenn man die Graphikkarte fürs Transcoding nutzen will.

Grundsätzlich wäre bei einer VM mit Docker halt klar, wieviel Ressourcen diese maximal verbrauchen kann.

Ich frage mich mittlerweile auch schon, ob ich mit Proxmox die richtige Wahl getroffen habe, weil es ja eine Virtualisierungsumgebung ist und ob z.B. Unraid am Ende geeigneter wäre für meine Anforderung (ich hatte Unraid auch schon probiert, gefällt mir vom Handling aber überhaupt nicht).

Es gibt ja auch noch andere NAS-Systeme und grundsätzlich könnte man sich auch direkt einen Linux-Server hinsetzen und alles andere darum basteln. Da du ja jetzt Proxmox hast, könntest du auch dir mal andere NAS-Systeme (Openmediavault und was es sonst so gibt) als VM installieren und gucken, was dir vom handling am meisten liegt.
Oder sind die Dienste am Ende dann doch zu viel für einen Server und ich brauche einen zweiten?

Schwer einzuschätzen, wenn die konkrete Auslastung nicht bekannt ist. Grundsätzlich würde ich erwarten, dass es passt, aber wie gesagt ohne die genaue Auslastung zu kennen, ist keine Aussage möglich.
 
Ja, definitiv MS SQL Server, funktioniert seit wenigen Jahren. Ich entwickle Datenbanken unter MS SQL Server, daher ist es für mich spannend zu sehen, wie es unter Linux funktioniert. Muss sagen: bis jetzt sehr gut. Ist noch nichts für Produktivumgebungen, aber zum Spielen und Testen sehr gut.

MS SQL Server unter Linux

(so, dann hab ich auch mal was zur Wissensbildung beitragen können :) )


Aktuell ist die CPU Auslastung im Summe unter 1%, RAM liegt bei 42%, das liegt aber hauptsächlich an der VM mit Docker.

Ich werde nochmal schauen, ob OMV oder Truenas auch eine Option ist, obwohl ich Proxmox selber schon sehr gut finde, und auch den Support hier im Forum. Man wird hier auch als Anfänger sehr wohlwollend behandelt und auch einfache Fragen werden freundlich und geduldig beantwortet, vielen Dank dafür.

Ich hab das neulich in einem Linux Forum auch anders erlebt. Da wurde ich gleich angemacht, weil ich eine Frage nicht richtig gestellt habe ...
 
  • Like
Reactions: Johannes S
LXC = Schlechter zu Sichern / kann unter umständen man den kompletten Proxmox Host zum Absturz bringen...
*wollte gerade einen schlechten politischen witz raushauen , aber hier ist Proxmox =) *love geht raus*

VM = "Just in Time"zu Sichern ohne Downtown.
Ist auf seiner eignen Insel. Egal was dort passiert , es bleibt auf der Insel .
Das ist mein Standard Satz auf diese frage. LXC zum testen & VM für Proaktiven Einsatz.
 
  • Like
Reactions: UdoB and Johannes S
Hallo,

ich habe nun meine ersten Gehversuche auf Proxmox hinter mir und bin erstmal sehr zufrieden, einfach auch, weil es funktioniert.
TOP!

Aktuell laufen bei mir auf meienr Synology einige Docker-Container. Diese Dienste möchte ich sukzessive nach Proxmox umziehen.
Ich habe nun einen LXC Container aufgesetzt und darauf dann Docker installiert mit den ersten Containern (Adguard, NGINX, Portainer, Watchtower).
Interessant, docker in lxc laufen zu lassen, ich hab immer VMs genommen. Ja, klingt prima, so lange kein Container "priviledge" braucht (z.B. um auf ZFS ACLs zugreifen zu können).

Demnächst sollen die Anwendungs-Dienste wie Paperless und Bitwarden folgen. Danach Jellyfin, YT-Download und weitere für den Heimgebrauch.

Ich verstehe zwar den Unterschied der beiden Ansätze, dennoch stellt sich bei mir die Frage, ob ich diese alle in eigenen, separaten LXC Containern laufen lassen soll oder gesammelt im bestehenden Docker?
Wenn Du jetzt schon docker Container hast, lass doch Deine n Docker Container in einem LXC Container laufen. Wenn etwas kommt, was damit nicht mehr so gut geht, dann erst würde ich weitere machen - sonst wird es schnell unnütz kompliziert.
Falls es unterschiedliche Backup-Anforderungen gibt, könnte man auch je ein LXC dafür machen (den einen alle paar Minuten und den anderen täglich sichern oder sowas).
Vielleicht ein zweiten LXC für eine Testumgebung.

Was ist da sinnvoll? Gibt es da irgendwelche Kriterien, wonach man das beurteilen kann? Oder ist es letztlich egal. An Docker gefällt mir, dass ich einmal für alle Container die Ressourcen definiere. Wo liegen die Vorteile bei LXC?
Der Hauptuntschied zwischen LXC und Docker (oder podman) ist meiner Meinung nach, dass Docker eher ein Deployment-Tool ist, also eine Form, in der man Software liefert, und LXC eher eine generische virtuelle Umgebung.

Rein praktisch startet Docker ein statisches Image (mit ein paar änderbaren Volumes oder so) und beim Update gibts ein neues Image. Das ist schön, wenn man gute, fertige Images kriegt (z.b: vom hub). Das ist doof, wenn man was ändern will (man muss ja eine docker build Umgebung machen).

LXC hat ein normales, persistent schreibbares Dateisystem und updated sich meistens selbst. Das ist schön, wenn man interaktiv damit arbeitet oder viel per Hand einstellen können will oder muss. Das ist doof, wenn man viele Nodes hat, auf denen das läuft (man will ja nicht auf jedem Node die gleichen Änderungen machen, aber auch dafür gibts Lösungen, ansible und so) oder man verschiedene Versionen schnell wechseln können will.

(zum Kernel hin benutzen dann alle das gleiche, cgroups2 und so.)
Wenn man viele Services hat, braucht man was "drumrum", da man nicht 10 oder 100 Docker Container per Hand verwalten will, dann nimmt man vielleicht lieber ein docker compose oder gar ein Kubernetes.

Ich frage auch deshalb, weil in vielen Tutorial Videos, die ich mir angesehen habe, dort sehr oft die 1 Dienst = 1 LXC Container gesehen habe.
Ich würde 1 Dienst = 1 Docker sehen, wobei "extern sichtbare Dienste" u.U. mehrere brauchen (und docker compose oder sowas nutzen)
Das geht mit LXC genauso, aber wenn ich fertige Dienst-images habe, werde ich die eher als OCI kriegen (also Image, also Docker).

Wenn man Gruppen von Docker containern hat, vielleicht "DSGVO relevant" und "Netzwerkdienste" oder so, bieten sich vielleicht hier ein LXC mapping an, oder "Dienste, die an jedem Standort immer laufen", oder sowas.

Ich brauche mehrere LXC, weil ich eigentlich immer ein LXC mit Samba habe, das in so ein blödes Active Directory muss, und das die ZFS ACLs benutzt. Da braucht man "priviledged" Container. Und weil ich anderes nicht priviledged laufen lassen möchte, hab ich da schon mal immer zwei.
Dann einen zum Testen für jeden Kollegen. Und zack ist er da, der Zoo...
 
Mag sein. Aber nicht für mich; daher schrieb ich oben: Choose your poison...

Ich leide auch etwas unter der generellen Konstruktion von Containern, egal ob LXC oder Docker: die Trennung zum Host ist nur hauchdünn und nachträglich aufgesetzt - was immer schlecht ist. Ursprünglich gab es weder Namespaces im Kernel noch sonst etwas, Container waren einfach nur bessere "chroot"s.
Ja, ist ja auch irgendwie die logische Fortsetzung davon (allerdings glaube ich, eher von BSD jails inspiriert).

Mittlerweile ist das wesentlich besser gelöst und wird allgemein als benutzbar eingestuft. Aber der einzige Kernel wird immer noch geteilt.
Na ja, das ist ja gerade das "Feature", so kann man z.b. schnell zwischen Containern kommunizieren. Bei docker macht man ja gern "localhost" Kommunikation, z.b. von Webserver zu Datenbank, das ist dann schnell. Der Container muss gar keine IP Adresse haben, ist wie ein Prozess, nur besser isoliert.
Gut, dass es im Kernel keine Bugs gibt...
Ja, für Sicherheitssachen würde ich auch immer VMs statt Container (und alles statt docker :D) nehmen.
Aber natürlich braucht man auch da den Hostkernel (allerdings über wesentlich leichter abzusichernde, kleinere Schnittstellen) und da kann was schiefgehen...
Woebi, seit der ganzen sidechannel Angriffe am besten dedizierte Hardware, denn die VM Isolation ist bei den meisten CPUs ja auch längst nicht mehr gut genug, wenn es jemand wirklich wissen will.

Frohe Weihnachten :-)

PS: bitte nicht missverstehen, ich hatte Container schon verwendet, als es sie noch gar nicht gab ;-) und sie stattdessen "OpenVZ" genannt wurden: https://en.wikipedia.org/wiki/OpenVZ. Aber heute kann meine Hardware KVM und Container sind für mich definitiv nur zweite Wahl.
Und erste Wahl ist software-emulation mit QEMU?
Das ist tatsächlich am sichersten, aber mit einer Performance von vielleicht 10% mir für den Alltag zu lahm (nutzte ich früher nur zum Entwickeln, sonst war's einfach zu lahm).
 
Jetzt muss ich doch nochmal eine Frage zur Ressourcenverwaltung LXC und Docker stellen.
Bei LXC Containern muss ich jedem Container seine Ressourcen zuweisen und sollte insbesondere den Ram nicht überbuchen. OK, verstanden.

Aber dann sehe ich aber doch einen Vorteil von Docker: Wenn ich Docker auf einer VM installieren, brauche ich nicht jedem Container einzeln die Ressourcen zuweisen. ich verstehe es so, dass Docker sich für alle Container der Ressourcen der VM nach Bedarf bedient. Da die meisten meiner Container ohnehin kaum etwas tun (Dashboard, Bitwarden, Paperless, usw.), könnte ich eine Reihe Container aufsetzen und muss nur einmal z.B. 8 GB Ram vergeben. Wenn ich alle Container einzeln als LXC aufsetzen würde, käme ich in Summe hws. auf eine höhere RAM-Zuweisung, wenn ich die empfohlenen RAM -Werte ansetze.

Verstehe ich das richtig? Hat da nicht Docker doch Vorteile?
Ja klar hat es Vorteile. Der Punkt ist übrigens auch ein Nachteil (ein kaputtes Paperlessng kann Bitwarden den RAM "klauen").
LXC Container kriegen übrigens CPU, RAM und disks alles "hotplug". Also im LXC ein top aufmachen, im Proxmox ein paar Kerne und GB hinzufügen, man sieht im Container sofort, dass mehr da ist (das geht mit VMs so nicht).
Bei RAM gitbs "ballooning", also nicht benötigter Speicher kann von anderen verwendet werden. Das ist nur doof, wenn alle den Speicher benötigen und dann nicht genug da ist (ich weiß leider nicht, wie sich das im Detail verhält, zu Hause ist's mir egal und produktiv verteile ich eh nur 50% des RAMs, den es wirklich gibt).