Ich habe also nun eine gigantisch große VM die nur Full-Backups unterstützt statt Snapshot, dazu kommt noch der Overhead eines einen realen-OS+Kernel+RAM+Swap+Management.
Das verstehe ich nicht. Die reguläre Backupfunktion von ProxmoxVE (vzdump mit vma-Archiven) kann immer nur full-Backups, egal ob vms oder lxcs. Der PBS macht dagegen immer ein Full- und inkrementelles Backup, egal ob Dateien, vms oder lxcs.
Ich verstehe ja, dass man lxcs (warum auch immer) bevorzugt, aber das Argument ist eher schwach.
Ich bin auch nicht pauschal gegen lxcs, es gibt natürlich usecases, wofür sie besser funktionieren (je nachdem wie man die geringere Isolation im Vergleich zu VMs in Relation zu den ebenfalls geringeren Ressourcenbedarf bewertet), etwa weil man die iGPU für Rendering unter jellyfin (braucht kein docker) nutzen möchte. Oder für ein pihole, was auch ohne docker installierbar ist und keine Netzwerkfreigaben (die mit bind-mounts in lxcs ja eher frickelig einzurichten sind) braucht. Aber es gibt eben auch Usecases, wo VMs besser funktionieren oder sogar die einzige sinnvolle Option sind.
Wurde früher im Proxmox Forum nicht noch gefragt was das Problem und das Szenario ist, um den Kontext besser zu verstehen? Müssen wir sofort auf Leute losgehen und sagen du machst es falsch, versehe ich das gerade richtig?
Das ist doch gar nicht der Punkt. Ich finde es völlig legitim, docker in lxcs zu benutzen, wenn man sich der Problematik bewusst ist und den damit verbundenen Folgen (Ausfall von Diensten, troubleshooting etc) leben kann. Mein Eindruck ist aber, dass viele Leute das nicht tun, sondern weil sie in irgendeinen clickbait-Youtube-Tutorial, reddit-Homelabbing-Forum das so empfohlen bekommen haben. Oder (noch schlimmer), weil sie eines dieser elendigen Helferskripte benutzen, aber nicht wissen (und auch nicht wissen wollen), wie die intern eigentlich arbeiten. Für paperless braucht man ja z.B. keine GPU für Rendering o.ä., da ist dann docker in einer vm deutlich stressfreier und das ist ja nicht die einzige Anwendung die auch ohne durchgereichte GPU o.ä. in einer VM problemlos betreibbar ist und wo man die Wahrscheinlichkeit für Überraschungen deutlich geringer ist als bei lxcs in docker.
Von daher finde ich es vollkommen legitim zu hinterfragen, ob die Leute einen Grund für eine nicht empfohlene Konfiguration haben und ob der denn tatsächlich valide ist. Falk hat ja bereits geschrieben, dass eine docker-VM nicht unbedingt viele Ressourcen braucht und es verbietet einen ja niemand alle docker-Container in eine VM zu packen, wenn man mit den Ressourcen haushalten muss.
Nun gibt es natürlich Anwendungen (wie immich), wo eine iGPU für Rendering praktisch ist, die sich aber nur mit docker installieren lassen. Das wäre für mich z.B. ein Fall, wo ich es absolut legitim finde, dass dann in einen lxc zu betreiben. Nur: Das sollte in meinen Augen die Ausnahme bleiben, um das Risiko zu minimieren. Mir persönlich ist meine Lebenszeit für troubleshooting zu schade, dafür darf gerne mein Homeserver (der eh die ganze Zeit an ist) mehr RAM verbrauchen.
BTW gab es hier im Thread auch durchaus Hinweise für (in meinen augen gefährliche Workarounds) wie das faktische Deaktivieren von AppArmor oder Downgrade des containerds, es ist also echt nicht so, dass hier nur auf die Leute "losgegangen" wurde, ohne ihnen bei ihren konkreten Problem zu helfen.
Zum aktuellen Problem gibt es auch schon einen Patch (der dann wohl bald seinen Weg in die pve-test und pve-no-subscription Repos finden wird), der AppArmor nicht komplett deaktiviert:
https://bugzilla.proxmox.com/show_bug.cgi?id=7006
Stattdessen werden einige Regeln angepasst, die das Nichtfunktionieren von nested Containern triggern. Das reduziert zwar auch die Sicherheit, ist aber natürlich besser als AppArmor ganz zu deaktivieren, da mit aktivierten Nesting diese Regeln (laut Aussage eines Incus-Entwicklers in den Kommentaren beim Bugticket) eh vergleichsweise einfach zu umgehen sind aber dafür immer noch die verbleibenden AppArmor-Regeln greifen. Und so macht AppArmor nicht mehr das Ausführen von docker (und anderen) Containern in einen lxc kaputt.
