Anfänger startet mit Proxmox: Ein paar Fragen

[ton11]

Moin zusammen!
Ich bin Umsteiger von einer Synology Disksstation (ds218+) auf einen Thin Client (HP EliteDesk 800 G4 Mini PC mit Intel vPro 8th Gen i5-8500T, mit 32GB RAM und 1TB SDD). Das Gerät steht bei mir im19" Rack im Keller. Auf der Synology hatte ich einige Programme im Docker laufen. Das wurde jetzt aber zuviel und deshalb der Umstieg. Die Synology bleibt aber noch wegen NAS und Videoüberwachung.
Ich habe das neue System noch nicht eingerichtet und wollte Euch fragen wie am geschicktesten vorgehen. Vorweg: Ich bin kein Linux Crack. Meist kopiere ich wenn nötig mir Lösungen zusammen. Der Umstieg war für mich auch deshalb wichtig, da es mit Docker manchmal etwas komplizierter war Updates zu fahren.
Ich möchte gerne folgendes installieren:

- Home Assistant (mit diversen IoT Protokollen)
- Grafana
- Influx DB 2
- EVCC
- AdGuard
- MQTT Mosquitto
- ggf Redis
- Windows

Viele der Pakete sind auch als LXC verfügbar. Mit Container Formaten habe ich hinsichtlich der Leistungsfähigkeit und Erweiterbarkeit weniger gute Erfahrungen gemacht. Bei einigen Tools macht es aber sicher keinen Sinn eine komplette VM zu fahren. Vielleicht könnt ihr mir raten wie ich vorgehen soll? Das wäre super. Ich dachte zum Beispiel daran, InfluxDB2, Grafana und Home Assistant auf eine gemeinsame VM (Ubuntu ?) zu packen, vllt noch den MQTT Broker dazu. AdGuard und EVCC dann als LXC. Windows logischerweise als VM. Was meint ihr dazu?

Danke!!!​

 

[maxim.webster]

Ich behaupte, Du hast Docker Container nicht korrekt eingesetzt und ich behaupte außerdem, dass die Verwendung von Proxmox, LXC und VMs die Komplexität nicht verringern wird.

 

[jim_os]

Ich kann Deinen Gedankengang nicht so ganz folgen. Einerseits schreibst Du

Container Formaten habe ich hinsichtlich der Leistungsfähigkeit und Erweiterbarkeit weniger gute Erfahrungen gemacht.

Andererseits dann wieder

Ich dachte zum Beispiel daran, InfluxDB2, Grafana und Home Assistant auf eine gemeinsame VM (Ubuntu ?) zu packen, vllt noch den MQTT Broker dazu.

Wie willst Du das denn dann machen ohne dafür dann Container zu nutzen?

Bei den Anwendungen die Du genannt hast würde ich wie folgt vorgehen:
HA = eine VM
Win = eine VM
Bei dem Rest kannst Du Dir dann überlegen ob Du dafür jeweils LXC nutzt oder eine weitere VM mit Containern. Ich würde halt LXC nutzen.

Bsp. von mir:


Ein Vorteil von Proxmox ist doch gerade u.a. der das man dann die Anwendungen auch getrennt und unabhängig voneinander laufen lassen kann und dann macht es eher wenig Sinn wenn man dann wieder alle möglichen Anwendungen in eine VM packt.

VG Jim

 

[ton11]

Ich behaupte, Du hast Docker Container nicht korrekt eingesetzt und ich behaupte außerdem, dass die Verwendung von Proxmox, LXC und VMs die Komplexität nicht verringern wird.

Ich behaupte, da hast Du wahrscheinlich recht. Das lag aber ganz sicher auch an der kastrierten Docker Lösung der Synology. Irgendwann fängt jeder mal an...

Ich kann Deinen Gedankengang nicht so ganz folgen.

Ok. Dann versuch ich mich noch einmal besser auszudrücken.

Ich hatte unter der Synology Lösung einen ioBroker Docker laufen. Dieser lies sich nicht einfach so updaten (dafür sind Docker ja offenbar auch nicht unbedingt gedacht), weil dort einfach viele Befehle nicht möglich waren. Mein Gedanke war halt, verschiedene (kleine) Dienst in eine gemeinsame VM auszulagern, ohne Docker oder LXC. Dadurch liesen sie sich, so zumindest meine Hoffnung, leichter updaten. Wenn das Blödsinn ist, haltet mich gerne davon ab.

Um mal konkret zu werden, @jim_os, du hast das Homeassistant OS als VM laufen? Und Zigbee nicht direkt im Homeassistant, sondern als LXC? Warum?

Danke Euch für die Hilfe!

 

[maxim.webster]

Dieser lies sich nicht einfach so updaten (dafür sind Docker ja offenbar auch nicht unbedingt gedacht), weil dort einfach viele Befehle nicht möglich waren.

Genau. Dafür sind Docker oder OCI Container nicht gedacht. Wenn ich iOBroker betreiben möchte, verwende ich das iOBroker Container Image und erstelle daraus, sowie aus extern verwalteten Nutzdaten (Konfiguration, Datenbank, etc.) eine Container-Instanz. Wenn es eine neue Version vom iOBroker Container Image gibt, schmeiße ich die laufende Container Instanz weg und erstelle eine neue aus dem aktuellen Image. Oder ich verwende Watchtower, der machst das für mich.

So, zum Thema:

Wenn Du Home Assistant OS verwenden möchtest, kommst Du um eine VM nicht herum, weil HASS.IO als Disk Image für NUC oder RPi kommt. Du kannst Home Assistant (in der non-OS-Variante) auch in einer VM betrieben, in der Du eine Container Runtime (überlicherweise Docker Engine) installierst und dort dann Home Assistant "Core" und weiter Services laufen lässt (z.B. Eclipse Mosquitto, eine Datenbank, etc.). Orchestriert wird das über Docker Compose, evt. noch Portainer als grafisches Management UI dazu.

Wenn Du noch andere Services hast, die MQTT oder die Datenbank verwenden, kann es sinnvoll sein diese als LXC oder in eigenen VMs zu betrieben. Da spielen auch so Überlegungen wie Lastverhalten und Hochverfügbarkeit eine Rolle.

VMs, als auch LXC Container stellen Dir eine Laufzeitumgebung für Deine Services zur Verfügung (üblicherweise ein Linux) um dessen Aktualisierung Du dich nach der Anlage selbst kümmen musst.

 

[ton11]

Wenn ich iOBroker betreiben möchte, verwende ich das iOBroker Container Image und erstelle daraus, sowie aus extern verwalteten Nutzdaten (Konfiguration, Datenbank, etc.) eine Container-Instanz. Wenn es eine neue Version vom iOBroker Container Image gibt, schmeiße ich die laufende Container Instanz weg und erstelle eine neue aus dem aktuellen Image. Oder ich verwende Watchtower, der machst das für mich.

Bisher hab ich fertig Container geladen und gestartet. Also die Anfängerversion. Watchtower kannte ich bisher noch nicht. Ich brauch halt oft grafische Oberflächen, damit ich klar komme.

Wenn Du Home Assistant OS verwenden möchtest, kommst Du um eine VM nicht herum, weil HASS.IO als Disk Image für NUC oder RPi kommt. Du kannst Home Assistant (in der non-OS-Variante) auch in einer VM betrieben, in der Du eine Container Runtime (überlicherweise Docker Engine) installierst und dort dann Home Assistant "Core" und weiter Services laufen lässt (z.B. Eclipse Mosquitto, eine Datenbank, etc.). Orchestriert wird das über Docker Compose, evt. noch Portainer als grafisches Management UI dazu.

Und ich dachte, installiere ich einfach ein Linux (bspw. Ubuntu) und betreibe HA einfach dort mit den entsprechenden zusätzlichen Services. Ja klar, ressourcenschonend ist das nicht, aber so hätte ich doch wenigstens ein System welches nicht begrenzt in seiner Leistungsfähigkeit ist. Denkfehler?

VMs, als auch LXC Container stellen Dir eine Laufzeitumgebung für Deine Services zur Verfügung (üblicherweise ein Linux) um dessen Aktualisierung Du dich nach der Anlage selbst kümmen musst.

Jau. Das hab ich verstanden.

Wenn Du noch andere Services hast, die MQTT oder die Datenbank verwenden, kann es sinnvoll sein diese als LXC oder in eigenen VMs zu betrieben. Da spielen auch so Überlegungen wie Lastverhalten und Hochverfügbarkeit eine Rolle.

Und Grafana und InfluxDB dann auch am besten als LXC? Letztlich ist alles nur Smarthome und nicht super kritisch, aber doch nervt es, wenn Alexa erst zwei Minuten später tönt, dass die Hintertür aufgegangen ist, der Gast aber schon beim ersten Bier am Küchentisch sitzt.

 

[jim_os]

du hast das Homeassistant OS als VM laufen?

Ja weil ich nicht die "abgespeckte" Docker Version von HA nutze.

Und Zigbee nicht direkt im Homeassistant, sondern als LXC?

Nein aktuell nutze ich Z2M und den MQTT Broker als Addon direkt unter HA. Meine Installation hier kann man auch nicht mit der eines Standard-Users vergleichen, weil ich einfach zu häufig an meinen Systemen und Kisten hier herumbastle. Ich nutzt HA jetzt seit ca. 4 oder 5 Jahren und seit dem ist HA schon x-mal auf irgendwelche anderen Kisten umgezogen. Mal lief das Bare Metal oder als VM unter Proxmox oder TrueNAS auf einem NUC, dann mal unter VMM auf einer meiner Synology NAS und dann wieder bare metal auf einer Fujitsu Kiste. Aktuell läuft es in einer Proxmox VM auf der Fujitsu Kiste. Auch die aktuell vorhandenen und im Screenshot zu sehenden LXC sind aktuell nur eher zum basteln und testen da, eben weil Z2M und MQTT Broker halt als Addon unter HA laufen.

Warum lasse ich Z2M, MQTT Broker und auch noch ein paar andere Anwendungen unter HA als Addon laufen und nicht in getrennten LXC?
a) Weil ich dann alles einheitlich unter HA administrieren kann. Incl. der Updates für diese Anwendungen.
b) Weil m.M.n. die Wahrscheinlichkeit größer ist das es bei den monatlichen HA Updates nicht zu so gravierenden Problemen mit den Anwendungen kommt, sofern es sich dabei um "offizielle" Anwendungen aus dem HA Addon Store handelt. Sprich ich gehe davon aus das die HA Entwickler sich eher und mehr darum kümmern das die unter dem HA Addon Store vorhandenen Anwendungen nach einem HA Update keine Probleme machen.
c) Weil ich dann bei einem HA Umzug alles in einem Paket habe, sprich bei einem HA Umzug "kümmert" sich die HA Restore Funktion darum das HA auf der dann anderen Kiste wieder so läuft wie vorher und ich muss nicht noch händisch irgendwelche Anpassungen an oder für irgendwelche Anwendungen machen die im LXC laufen und bei HA eingebunden wurden.

Ja es gibt natürlich auch User die quasi genau das Gegenteil machen und alles was nur geht von HA auslagern und ja auch dadurch ergeben sich für den ein oder anderen User halt die ein oder anderen Vorteile, aber ich mache es hier für mich und für mein aktuelles HA Szenario, halt nicht.

VG Jim

 

[ton11]

Warum lasse ich Z2M, MQTT Broker und auch noch ein paar andere Anwendungen unter HA als Addon laufen und nicht in getrennten LXC?
a) Weil ich dann alles einheitlich unter HA administrieren kann. Incl. der Updates für diese Anwendungen.
b) Weil m.M.n. die Wahrscheinlichkeit größer ist das es bei den monatlichen HA Updates nicht zu so gravierenden Problemen mit den Anwendungen kommt, sofern es sich dabei um "offizielle" Anwendungen aus dem HA Addon Store handelt. Sprich ich gehe davon aus das die HA Entwickler sich eher und mehr darum kümmern das die unter dem HA Addon Store vorhandenen Anwendungen nach einem HA Update keine Probleme machen.
c) Weil ich dann bei einem HA Umzug alles in einem Paket habe, sprich bei einem HA Umzug "kümmert" sich die HA Restore Funktion darum das HA auf der dann anderen Kiste wieder so läuft wie vorher und ich muss nicht noch händisch irgendwelche Anpassungen an oder für irgendwelche Anwendungen machen die im LXC laufen und bei HA eingebunden wurden.

Cool. Danke. Das hab ich verstanden. Dann mach ich das auch so, klingt Nerven schonender. Nerven wird mich der Umzug von ioBroker zu HA schon genug kosten.

Ja weil ich nicht die "abgespeckte" Docker Version von HA nutze.

Bin ja noch neu bei HA. Nicht abgespeckt heißt, du hast das HAOS installiert, richtig? Da komme ich dann auch an die Addons? Das ist bei meiner Docker Testversion gerade nämlich noch nervig, Homematic fehlt mir so komplett.

 

[jim_os]

Jepp HAOS VM und noch einmal jepp. Bei der HA Docker Variante gibt es den HA Addon Store halt nicht,

https://www.home-assistant.io/addons/

weil das ja auch alles Docker Anwendungen sind und man schlecht einen Docker in einem Docker installieren kann.

Edit: Über den HA Addon Store lassen sich dann auch noch weitere Repos einbinden.


Für andere/weitere Integrationen gibt es dann noch den Home Assistant Community Store (HACS): https://www.hacs.xyz/

Was dann die HAOS Installation als VM unter Proxmox betrifft. Entweder selber eine VM dafür erstellen und einrichten oder halt die Proxmox Helper Scripts des leider verstorbenen Users tteck dafür benutzen:

https://tteck.github.io/Proxmox/
https://community-scripts.github.io/ProxmoxVE/

VG Jim

 

[maxim.webster]

b) Weil m.M.n. die Wahrscheinlichkeit größer ist das es bei den monatlichen HA Updates nicht zu so gravierenden Problemen mit den Anwendungen kommt, sofern es sich dabei um "offizielle" Anwendungen aus dem HA Addon Store handelt.

Hat man ja beim Update von Z2M 2.0 gesehen

Egal.

 

[jim_os]

Z2M ist kein "offizielles" HA Addon und auch nicht im HA Addon Store vorhanden.
Die HA Entwickler kümmern sich um ZHA und weniger im Z2M.

BTW: Ich hatte hier genau Null Probleme mit dem Z2M Update auf Version 2.0. Wenn man vor dem Update mal einen Blick in die wirklich sehr ausführlichen Release Notes und Infos zu dem Update wirft - was viele User leider (scheinbar) nicht machen - dann weiß man was zu tun ist und dann kommt es eigentlich auch nicht wirklich zu Problemen.

VG Jim

 

[maxim.webster]

Nochmal anders:

- ein einzelner Prozess (z.B. MQTT) in einer VM macht wenig Sinn, es sei denn der Prozess/Service stellt seinerseits eine Laufzeitumgebung für weitere Services dar. Also zum Beispiel ein Docker Host oder ein Application Server
- Docker Container in LXC funktioniert zwar, wird aber nicht empfohlen

Somit bleibt dir eigentl. nur, einzelne Prozesse „nativ“ in LXC oder mehrere Prozesse „nativ“ oder als Docker Container in eine VM zu betreiben.

Mit „nativ“ meine ich aus den Paket-Quellen des Betriebssystems, bei Debian Linux zum Beispiel apt. Debian hat mit unattended-upgrades auch die Möglichkeit einer weitgehenden, automatischen Aktualisierung.

 

[maxim.webster]

Z2M ist kein "offizielles" HA Addon und auch nicht im HA Addon Store vorhanden.
Die HA Entwickler kümmern sich um ZHA und weniger im Z2M.

https://github.com/zigbee2mqtt/hassio-zigbee2mqtt

Steht „official“ drüber.

Ich hatte auch keine Probleme bei der Migration standalone, weil ich die Breaking Changes beachtet habe.

Ich hab aber einen sehr zerpflückten Setup: HA und Homegear (für Homematic), Watchtower als Docker Compose in einer VM, Z2M als Container auf einem RPi (weil da der Adapter dran hängt) und MQTT als HA-LXC, damit die HA VM bei Bastelarbeiten runterfahren kann, ohne dass Nachrichten verloren gehen.

 

[jim_os]

Steht „official“ drüber.

Ist jetzt zwar eine "Spitzfindigkeit", aber trotzdem. Das "Official" was auf der Webseite von Z2M steht bezieht sich darauf das es sich dabei um das offizielle Addon handelt das es von Z2M für HA gibt, aber nicht darauf das das ein offizielles Addon von HA selber ist. Z2M ist kein offizieller Bestandteil des HA Addon Stores und so hatte ich das ja auch gepostet.

Das hier sind aktuell die offiziellen HA Addons im HA Addon Store und wie man sehen kann gehört Z2M nicht dazu.


Weiterhin gibt es dann auch noch die Home Assistant Community Addons und die Addons - wie z.B. Z2M - die man selber per zusätzlichen Repo installieren kann.


Edit: Ja wenn man z.B. den MQTT Broker auch noch für andere Dinge außer HA nutzt kann es schon Sinn machen den in einen LXC zu packen, eben weil - wie Du ja schon geschrieben hast - dieser weiterhin von anderen Anwendungen Daten empfangen kann wenn HA mal nicht läuft. Ich pers. würde einem HA Einsteiger aber empfehlen, auch wenn er sich bereits Proxmox installiert hat, erst einmal mit HA Addons zu arbeiten, weil es m.M.n. leichter ist diese zu installieren und einzurichten und man dazu dann auch mehr Infos in irgendwelchen HA-Foren findet und bekommt. Das auslagern von Anwendungen in LXC kann man später ja ggf. immer noch machen.

VG JIm

 

[maxim.webster]

- Home Assistant (mit diversen IoT Protokollen)
- Grafana
- Influx DB 2
- EVCC
- AdGuard
- MQTT Mosquitto
- ggf Redis
- Windows

Wir haben voll den Fokus verloren und quatschen über Home Assistant.

Vorab: Mit genau einem Proxmox Host ist es eigentlich egal wie Du verteilst, denn Hochverfügbarkeit oder Redundanz hast Du eh nicht. 2 Nodes und ein QDevice sind Minimum, bevor man sich über diese Dinge Gedanken macht.

Vorschlag:

VM1:
* Home Assistant OS, mit Add-Ons für MQTT, etc. Da HA OS als "Applicance" kommt, kannst Du die VM für nichts anderes verwenden

VM2:
* Windows (geht nicht anders)

LXC:
* InfluxDB
* Grafana
* Redis
* AdGuard
* EVCC

Als OS entweder Debian Linux oder Alpine Linux, sofern es keine CT Templates dafür gibt. AdGuard und EVCC wären für mich auch die ersten Kandidaten, die ich "clustern" würde, wenn 2 Nodes da sind, da sie essentiell sind (bei AdGuard weiß ich es, bei EVCC vermute ich es).

Ich finde persönlich keinen wirklichen Griff an LXC, irgendwie sind die mir für einzelne Services zu fett und für Server zu wenig isoliert. Die CT Templates und die Helper Scripts kompensieren letztendlich nur, was OCI/Docker Container ab Werk können. Darum bastel ich gerade an der top-of-the-hill-kompliziert-aber-dann-mit-allem Lösung: VMs mit Talos Linux als Kubernetes nodes.

 

[jim_os]

und quatschen über Home Assistant

Ich vermute mal das HA für @ton11 aktuell auch der Grund ist warum er sich überhaupt mit Proxmox beschäftigt.

Wenn ich das richtig einschätze und so hat es @ton11 ja auch geschrieben, hat er bisher seine DS218+ für die Anwendungen genutzt und somit dürften seine Kenntnisse bzgl. Linux eher rudimentär sein. Würde ich mit Proxmox anfangen würde ich an seiner Stelle mir da auch gar nicht so viele Gedanken darüber machen ob und welche Anwendungen ich jetzt in welche Container stecke und unter welchen Linux BS ich dann ggf. auch noch Docker nutze. Ganz zu schweigen von Nodes und Cluster. Ja natürlich macht ein gute und vernüftige Planung im Vorfeld Sinn und erspart einem später ggf. irgendwelche Nacharbeiten oder Änderungen, aber man muss halt auch immer im Hinterkopf behalten was für User sich aus welchen Gründen mit Proxmox neu beschäftigen. Kaum ein "Otto-Normal-Anwender" ist dazu bereit sich Stunden und Tage lang in das Thema Proxmox einzulesen und sich im Vorfeld alle möglichen Dinge zu überlegen und/oder zu planen. Ob das nun gut oder schlecht ist ist eine andere Frage.

Wie ich ja schon geschrieben hatte:

Bei den Anwendungen die Du genannt hast würde ich wie folgt vorgehen:
HA = eine VM
Win = eine VM
Bei dem Rest kannst Du Dir dann überlegen ob Du dafür jeweils LXC nutzt oder eine weitere VM mit Containern. Ich würde halt LXC nutzen.

Alles was es dann als Addon für HA gibt unter HA installieren und falls das nicht geht oder nicht gewollt ist, schauen ob es ein passendes LXC Script von tteck dafür gibt. Wenn es dafür keinen bestimmten Grund geben sollte würde ich eine extra Linux VM nur für Docker gar nicht nutzen.

D.h. für eine Proxmox Einsteiger so einfach wie möglich und so umfangreich wie nötig. Insbesondere dann wenn es - wie hier - primär um HA geht. Dann erst eine Weile mit Proxmox herumspielen und -experimentieren und dann kann man anfangen Proxmox anhand dem dann hoffentlich mehr an Wissen und Erfahrungen, individueller und ggf. umfangreicher aufzubauen und zu nutzen.

VG Jim

 

[ton11]

Ahhh 1000 Dank Euch. Jetzt bin ich etwas erschlagen von den Begriffen. Da muss ich erstmal ChatGPT befragen...

Ja wenn man z.B. den MQTT Broker auch noch für andere Dinge außer HA nutzt kann es schon Sinn machen den in einen LXC zu packen, eben weil - wie Du ja schon geschrieben hast - dieser weiterhin von anderen Anwendungen Daten empfangen kann wenn HA mal nicht läuft.

Ja, den würde ich gerne unabhängig haben. Das wäre mir wichtig. Ich versuche nach Möglichkeit für Geräte die mir sehr wichtig sind, wie zum Beispiel die zwei openWB, diese unabhängig vom Smarthome laufen zu lassen, zumindest was die Grundfunktionen angeht.

Als OS entweder Debian Linux oder Alpine Linux, sofern es keine CT Templates dafür gibt.

Meinst Du dann ein OS für alle Dienste? Also ein vollständiges Debian?


Ansonsten klingt das für mich sehr schlüssig was ihr mir ratet. Ich werde versuchen es so umzusetzen und mich sicher wieder melden, wenn ich fest stecke. Danke schön!

 

[ton11]

. Würde ich mit Proxmox anfangen würde ich an seiner Stelle mir da auch gar nicht so viele Gedanken darüber machen ob und welche Anwendungen ich jetzt in welche Container stecke und unter welchen Linux BS ich dann ggf. auch noch Docker nutze.

Irgendwomit muss man sich ja beschäftigen, wenn die Post so lange braucht den "neuen" Server zu liefern.
Aber mal Spaß beiseite. Ich finde das schon wichtig, denn wenn ich mir meine Konfiguration aktuell ansehe, sind da doch einige Dinge vermurkst, die ich lieber beim nächsten Mal gleich von Anfang an richtig mache. Im Nachgang die Dinge glatt ziehen, ist ja oft mit mehr Arbeit verbunden...

 

[maxim.webster]

Meinst Du dann ein OS für alle Dienste? Also ein vollständiges Debian?

Es ist immer ein OS in VM oder Container. Welche „Geschmacksrichtung“ man nimmt, bleibt einem selbst überlassen.

Alpine ist die Basis vieler Docker Container, weil es sehr reduziert ist. Aber er ist ein vollwertiges Linux und kann aufgebohrt werden.

Bei Debian oder Ubuntu bieten sich die „minimal“ oder „server“ Varianten an, weil kein Desktop gebraucht wird. Die sind dann auch ausreichend klein.

 

[jim_os]

Natürlich sollte man sich schon ein paar Grundkenntnisse zulegen, aber man sollte es zu Anfang auch nicht gleich zu kompliziert machen. Bei Dir war ja vermutlich das "Problem" das Du von der DS her nur den Container-Manager (früher Docker) und max. noch VMM kennst/kanntest und man das halt nicht wirklich mit Proxmox, LXC und VMs vergleichen kann. Somit hattest Du irgendwie das Thema Docker im Hinterkopf. Aber ok das ist ja auch egal.

Ja, den würde ich gerne unabhängig haben.

Ist ja auch kein Problem. Einfach den MQTT Broker per tteck Script unter Proxmox als LXC automatisch einrichten lassen, das Thema Usereinrichtung im Nachgang beachten und erledigen und schon läuft der MQTT Broker als LXC. Wenn man sich etwas mehr/besser mit Proxmox auskennt dauert die Installation und Einrichtung davon vielleicht 5 - 10 Minuten. Nur für den MQTT Broker braucht es keine extra Linux VM. Ups - ich wiederhole mich gerade.

OK die verschiedenen Möglichkeiten kennst Du ja jetzt und Du kannst diese ja mal durchspielen und testen. Am Ende übt das ja auch den Umgang mit LXC und VMs und evtl. wieder platt machen kann man eh alles.

VG Jim