Proxmox in Docker klingt falsch, und genau deshalb konnte niemand wegsehen

Manche Projekte kommen mit einem sauberen Pitch daher. Andere treten die Tür auf, tragen einen falschen Schnurrbart und verlangen vom Raum eine Erklärung, warum er wütend ist, und „Proxmox in einem Docker-Container“ gehört ganz klar zur zweiten Sorte. Die Idee ist einfach genug: Proxmox VE so verpacken, dass es auf einem bestehenden System über Docker läuft, damit Leute die Plattform testen können, ohne eine ganze Maschine dafür zu opfern. Der Ersteller stellte es als reibungsarmen Spielplatz für Einsteiger dar, besonders für Leute, die Docker bereits verstehen, aber Proxmox noch nie angefasst haben. Eine ruhige technische Bewertung war die erste Reaktion der Community eher nicht. Es war, als sähe man jemandem zu, der einen Hypervisor in eine Brotdose packt.

Der Witz schrieb sich von selbst

Die lustigsten Antworten hatten die Aufgabe sofort verstanden. Jemand rief praktisch: „Seht euch an, wie sie meinen Jungen abgeschlachtet haben“, was den emotionalen Schaden einfing, den manche Proxmox-Nutzer beim ersten Anblick empfanden. Ein anderer nannte es natürlich „Proxception“. Jemand fragte, wie tief die Verschachtelung gehen könne: Proxmox in Docker, in einer Debian-VM, in Proxmox, in Docker, in einer weiteren VM, alles auf Hardware, auf der Proxmox läuft. Eine echte Frage war das nicht, eher der Klang eines Homelab-Gehirns, das eine verbotene Treppe sieht und darauf zurennt.

Die Meme-Energie senkte die Temperatur, weil die Leute sich über das Projekt lustig machten und gleichzeitig davon fasziniert waren. Das Ganze hatte denselben Reiz wie Doom auf einem Drucker oder Kubernetes auf einem Raspberry Pi, angetrieben von reiner Bosheit. Sinnvoll ist es vielleicht nicht, lehrreich aber fast sicher. Eine bestimmte Art von Ingenieurs-Neugier beginnt mit „das fühlt sich falsch an“ und endet mit einem überraschend nützlichen Werkzeug. Die Kommentare waren voll von dieser Spannung aus Abscheu, Gelächter und ein bisschen „Moment, könnte das tatsächlich funktionieren?“

Der nützliche Teil ist fast zu offensichtlich

Ohne den Horrorfilm-Rahmen ergibt der Pitch durchaus Sinn. Proxmox verlangt normalerweise eine eigene Maschine oder zumindest eine ordentliche Installationsumgebung. Für Leute mit Ersatzhardware ist das in Ordnung, für Einsteiger ist es eine Mauer. Ein dockerisiertes Proxmox senkt diese Hürde: Man fährt einen Container hoch, stöbert in der UI herum, versteht den Workflow, macht Dinge kaputt, löscht den Container und fängt von vorn an. Wer von Docker kommt, findet das natürlich, und wer entscheiden will, ob Proxmox einen echten Host verdient, bekommt eine billige Probefahrt.

Der Ersteller stellte auch eine mutige Performance-Behauptung auf: Virtuelle Maschinen sollten sich wie eine normale Bare-Metal-Installation verhalten, weil sie direkt auf das KVM-Kernel-Modul des Hosts zugreifen, ohne zusätzliche Virtualisierungsschicht dazwischen. Mit diesem Detail rückte das Projekt von „lustiges verfluchtes Experiment“ zu „hm, vielleicht doch“. Manche fragten sich, was man sonst noch damit anfangen könnte, etwa einen dreiknotigen Proxmox-Cluster als Container auf einer Maschine, ein Trainingslabor oder eine Demo-Umgebung für Dokumentation, Videos oder Klassenzimmer. Plötzlich hatte die verfluchte Brotdose einen Job.

Die Puristen hatten einen Punkt

Gespielt war das Unbehagen trotzdem nicht. Proxmox soll das Fundament unter den Workloads sein und kein weiterer Container im Stapel. Es verwaltet Storage, Netzwerk, VMs, Container, Cluster, Backups und viel Verhalten auf Host-Ebene. Packt man das in Docker, klingt das danach, als würden sich zwei Kontrollebenen ums Lenkrad streiten. Selbst wenn das Projekt technisch funktioniert, darf man fragen, wo die Grenzen liegen: bei Netzwerk-Eigenheiten, Geräte-Zugriff, Storage-Annahmen, Upgrades, Sicherheit und Support-Erwartungen. Niemand will, dass ein Anfänger eine clevere Testumgebung mit einem Produktivsystem verwechselt.

Hier fühlte sich das skeptische Lager auf sicherem Grund. Ein Kommentator scherzte darüber, es in einem Debian-LXC laufen zu lassen, dann Docker, dann noch ein Proxmox, dann noch ein LXC, „und immer weiter die Wasserrutsche runter, um zu sehen, wo es endlich bricht.“ In dem Witz steckt auch eine Warnung. Verschachtelte Infrastruktur kann einem viel beibringen, sie kann aber auch Probleme erzeugen, die so seltsam sind, dass sie in keine normale Dokumentation passen. Steckt die Plattform selbst in einer weiteren Abstraktion, wird jeder Fehler ein bisschen schwerer zu erklären, und der Stack-Trace wächst sich zum Stammbaum aus.

Die Homelab-Community liebt so etwas insgeheim

Ausprobieren werden es wahrscheinlich genau die Leute, die am lautesten darüber lachen. Die Homelab-Kultur lebt von praktischen Bedürfnissen, aber auch von wunderschön unnötigen Experimenten. Jemand wollte NixOS mit ins Spiel bringen, ein anderer steigerte den Gag zu rootless Podman, und jemand erinnerte sich an alte Versuche, VMs in ESXi unter VirtualBox unter Windows laufen zu lassen, was offenbar nicht gut ging. In diese Abstammungslinie gehört das Projekt, weit weg von Enterprise-Architekturdiagrammen und nah an der Frage „was passiert, wenn ich das mache?“ um Mitternacht.

Schlecht ist das nicht, denn viel ernsthaftes Infrastrukturwissen beginnt als Unsinn. Man lernt, wo KVM lebt und was Docker isolieren kann und was nicht. Man lernt, warum Storage-Passthrough wichtig ist, warum Netzwerk seltsam wird, warum privilegierte Container mächtig und beängstigend sind und warum „es bootet“ etwas anderes ist als „ich vertraue ihm meine Daten an“. Eine dockerisierte Proxmox-Box ist wahrscheinlich nicht die Zukunft der Produktivvirtualisierung. Als Lehrmittel, Demo-System oder Weg, neugierige Leute klicken zu lassen, ohne eine Maschine neu zu partitionieren, hat sie aber eine echte Daseinsberechtigung.

Die verfluchte Demo könnte die beste Einstiegsdroge sein

Die emotionale Spaltung ergibt vollkommen Sinn. Langjährigen Proxmox-Nutzern kommt es vor, als stelle man das Fundament eines Hauses auf Rollschuhe. Docker-native Einsteiger sehen eine freundliche Haustür, und für die Chaos-Ingenieure ganz hinten ist es eine Einladung, eine Infrastruktur-Matroschka zu bauen, bis etwas schreit. Alle drei Reaktionen sind berechtigt, denn das Projekt ist seltsam und clever zugleich. Es sollte wahrscheinlich mit einem riesigen Aufkleber kommen: „Nicht für Produktion, außer du weißt genau, welchen Schmerz du dir einkaufst.“

Am stärksten ist an dem Projekt die Idee, dass Zugang zählt. Leute probieren Tools aus, wenn der erste Schritt einfach ist. Ein Container, den man starten, untersuchen, zerstören und neu aufbauen kann, schüchtert weniger ein, als eine Ersatzmaschine zu löschen oder verschachtelte Virtualisierung von Hand einzurichten. Manche Nutzer werden sich also weiter empören, andere weiter Memes posten. Irgendwo wird aber ein Neuling das hier ausprobieren, lernen, was Proxmox tut, und es irgendwann richtig auf echter Hardware installieren. Wer darin ein Massaker sah, übersieht einen überraschend effektiven Onboarding-Trichter mit Clownsnase.