Proxmox bringt LXC als Alternative zur klassischen VM mit. Das LX steht für LinuX, das C für Containers. LXC ist also ebenfalls ein Container System, aber es ist voll in Proxmox integriert.
Docker ist auch nett, vor allem, weil die vorgefertigten Images mit dem entsprechenden Hintergrundwissen extrem einfach zu starten und jederzeit wiederherstellbar sind - Container wegwerfen und neu starten - fertig.
Die Einstellungen und volatilen Daten liegen in sogenannten Volumes und werden nicht mit gelöscht. So ist auch ein Upgrade ohne Schrecken möglich und das Backup ist wirklich auf die reinen Daten beschränkt, was Platzersparnis bedeutet.
Dafür muss man aber relativ viel dazu lernen (zumindest wenn man es richtig machen will).
LXC kann man als Zwischending zwischen Docker und VM betrachten.
Die Kapselung zum Host ist fast so gut wie bei einer VM, aber der ganze Overhead entfällt. Das Gastsystem verwendet einfach den Kernel vom Host mit, ist aber auf ein Minimum beschnitten.
Vorteil ist hier, dass man wie gewohnt einfach alles in einen Container rein packt (Bei Docker wird gewöhnlich nur eine Anwendung in den Container gepackt. Grafana, InfluxDB, Samba, läuft alles in eigenen Containern). Dennoch spart man enorm an Leistung, weil der Unterbau nicht emuliert werden muss.
Sämtliche Zugriffe werden vom Host kontrolliert, wie bei einer VM, aber eben in schlank.
Das Debian Image benötigt z.B. gepackt ganze 123 MByte, wobei ein paar Tools für den Komfort fehlen, die aber exakt wie bei einer VM nachinstalliert werden können - es gibt für den Anwender erst mal keinen Unterschied zu einer VM oder einem "echten" Rechner.
Einschränkungen ergeben sich dann an Stellen, wo erweiterte Rechte gebraucht werden, denn der Container läuft gewöhnlich unprivilegiert. Man kann ihn auch privilegiert laufen lassen, das bringt aber andere Nachteile mit sich, ist also keine "Immer an" Option, sondern muss von Fall zu Fall entschieden werden. Samba als Dienst braucht z.B. ein paar extra Einstellungen, genau wie NFS.
Ich betreibe bei mir - historisch gewachsen - openHAB getrennt von InfluxDB, MariaDB und Grafana, das sind bei mir also vier Container, die jeder für sich nur einen kleinen Bruchteil von dem benötigen, was eine einzige VM braucht. Insgesamt sieht das dann schon wieder anders aus, aber hier geht es ja auch um das Separieren von Diensten.
MariaDB nimmt bei mir die Daten von openHAB so nebenher entgegen, es kümmert sich um die Messwerterfassung von volkszähler genauso wie um die Telefondaten, die DVD Sammlung liegt hier und auch die Daten des EPG für meine vdr Systeme (das allein sind ca. 7 GByte, weil auch die Bilder als blobs in der Datenbank liegen).
Gewöhnlich müsste ich für jedes der Systeme eine eigene Datenbank mit in den Container einbauen, hätte also fünf Instanzen von MariaDB laufen, statt jetzt eine.
Ähnlich sieht es in Bezug auf openHAB aus. Ich habe drei openHAB Systeme, die alle auf die gleiche Infrastruktur zugreifen (es handelt sich dabei um ein Produktivsystem und zwei Testsysteme...) Mit VMs würden die Ressourcen schnell knapp, mit LXC ist das kein Problem. Eine Maschine, die ausschließlich einen ssh Zugang bietet (Passwort ist ausgeschaltet, man kommt also nur mit Private Key rein) benötigt gerade mal 20 MByte RAM und bietet praktisch keine Angriffsfläche, obwohl sie ansonsten "ungeschützt" direkt von außen erreichbar ist. Aber es ist eben auch nur der eine Port für ssh erreichbar, sonst nichts.
Wenn man also auf relativ kleinen Rechnern mit Proxmox virtualisiert, sollte man sich unbedingt LXC anschauen, aus Anwendersicht gibt es kaum Unterschiede zu einer klassischen VM, bis auf die Tatsache, dass ein Container im Allgemeinen fast unmittelbar nach dem Einschalten verfügbar ist, während eine VM erst vollständig booten muss.
openHAB lässt sich auch in einem LXC prima mittels openHABian einrichten, man muss nur ein paar Anpassungen in der openhabian.conf vornehmen, weil die für ARM System optimiert ist. Ob man dann die Datenbanken auslagert oder im selben Container betreibt, sich Geschmackssache
64-Bit-System auch ein 64-Bit Java zu nutzen.