!Home Assistant auf Proxmox VM

Irgendwann reicht der Raspberry Pi nicht mehr. Nicht weil Home Assistant so viel Rechenleistung bräuchte, sondern weil man anfängt, mehr daneben stellen zu wollen: Zigbee2MQTT als separaten Container, einen kleinen MQTT-Broker, Frigate für Kameraerkennung, vielleicht noch einen WireGuard-Endpunkt. Auf dem Pi kämpfen die Dienste um Speicher und IO-Bandbreite, bis irgendwann eine SD-Karte aufgibt oder ein Neustart den ganzen Abend kostet.

Proxmox ist in dieser Situation der übliche Ausweg. Und Proxmox mit Home Assistant OS als virtuelle Maschine ist heute die Standardempfehlung in der Community. Warum das so ist, was das Community-Skript eigentlich macht, wo USB-Passthrough für Zigbee-Sticks zum Problem wird, und für wen das alles gar nicht nötig ist, erklärt dieser Artikel.

Die vier Installationsmethoden und warum es heute einfacher geworden ist

Wer sich zum ersten Mal mit Home Assistant beschäftigt, trifft auf vier Begriffe: Home Assistant OS (HAOS), Supervised, Container und Core. Die vier Namen sind tatsächlich vier verschiedene Dinge, keine Marketing-Varianten.

Home Assistant OS ist ein vollständiges, schlankes Betriebssystem, das ausschließlich für HA gebaut wurde. Es bringt einen Supervisor mit, der Add-ons direkt aus dem offiziellen Store installierbar macht: Mosquitto, Zigbee2MQTT, Node-RED, ESPHome, Frigate. Updates laufen über die HA-Oberfläche. Das System weiß, was es tun soll, und macht außerhalb davon nichts. Home Assistant Container ist ein Docker-Image ohne Supervisor. Der Add-on-Store fehlt. Wer Mosquitto oder Zigbee2MQTT will, betreibt diese als separate Container und konfiguriert sie selbst. Funktioniert gut für Leute, die ohnehin mit Docker arbeiten und kein Problem damit haben, mehrere Dienste parallel zu verwalten. Home Assistant Core war die reine Python-Installation. Home Assistant Supervised war der Versuch, den Supervisor auf ein fremdes Betriebssystem aufzupfropfen.

Letztere zwei Varianten werden ab Home Assistant 2025.12 nicht mehr offiziell unterstützt. Das Home-Assistant-Team hat im Mai 2025 auf dem Blog angekündigt, Core und Supervised einzustellen. Begründung: Zusammen deckten sie weniger als sechs Prozent der Installationen ab, erzeugten aber überproportional viele Supportprobleme, die schwer lösbar waren. Wer noch eine Supervised-Installation betreibt, sollte migrieren.

Das vereinfacht die Entscheidung. Auf Proxmox bleiben zwei sinnvolle Optionen: HAOS als VM oder HA Container in einem LXC-Container. Für die allermeisten ist HAOS die richtige Wahl, aus einem Grund: der Add-on-Store. Wer jemals manuell einen Zigbee2MQTT-Container konfiguriert hat, weiß, wie viel Arbeit der Add-on-Store abnimmt.

Warum eine VM und kein LXC-Container

Proxmox bietet zwei Virtualisierungsformen: vollständige virtuelle Maschinen und LXC-Container. LXC teilt den Linux-Kernel des Hosts, ist leichter und startet schneller. VMs emulieren vollständige Hardware, laufen komplett isoliert und können jeden Betriebssystem-Stack ausführen.

Für HAOS ist die VM die richtige Wahl. Der Grund ist USB-Passthrough: Zigbee-Sticks, Z-Wave-Adapter und andere serielle Geräte lassen sich in einer VM sauber durchreichen. In einem LXC-Container ist das deutlich komplizierter und erfordert manuelle udev-Regeln und cgroup-Konfigurationen, die bei Kernel-Updates kaputtgehen können.

Dazu kommt: HAOS ist für bare-metal oder VM-Betrieb entworfen. Es funktioniert in einem LXC-Container zwar technisch, aber nicht offiziell unterstützt und mit mehr Handarbeit verbunden. Wer ohnehin Proxmox nutzt, hat die Ressourcen für eine VM. Der Overhead ist gering.

Das Community-Skript

Früher war die HAOS-Installation auf Proxmox ein mehrstündiger Prozess: HAOS-Image herunterladen, entpacken, als Disk in eine manuell konfigurierte VM importieren, Boot-Order setzen, VM-Parameter anpassen. Kein großes Drama, aber viele Schritte, bei denen man Tippfehler einbauen kann.

Ein Entwickler, der unter dem GitHub-Handle tteck bekannt war, hat das mit einer Sammlung von Shell-Skripten deutlich vereinfacht. Die Skripte automatisierten genau diese Schritte: VM anlegen, Image herunterladen, importieren, konfigurieren, starten.

Im September 2024 teilte tteck in einer GitHub-Discussion mit, dass er an unheilbarem Appendixkrebs erkrankt war. Das Original-Repository tteck/Proxmox wurde am 2. November 2024 archiviert. tteck ist kurz danach verstorben.

Die Community hat das Projekt übernommen. Unter dem Namen community-scripts/ProxmoxVE läuft es heute weiter, mit über 400 Skripten und wöchentlichen Releases. Die offizielle Adresse ist community-scripts.github.io/ProxmoxVE beziehungsweise community-scripts.org. Das Skript für HAOS heißt haos-vm.sh.

Der Installationsbefehl, den man in der Proxmox-Shell ausführt:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/haos-vm.sh)"

Das Skript fragt, ob man die Standardeinstellungen übernehmen oder eigene Werte angeben will. Standardmäßig legt es eine VM mit 2 CPU-Kernen, 4 GB RAM und 32 GB Disk an, lädt das aktuelle HAOS-Image herunter und importiert es. Der Fortschritt ist im Terminal sichtbar. Am Ende gibt das Skript die VM-ID und die lokale IP-Adresse aus.

Ein Hinweis zur Sorgfalt: Das Skript überprüft die Signatur des heruntergeladenen Images nicht. Wer sicherheitssensibel arbeitet, kann den SHA256-Hash manuell gegen die offizielle Home-Assistant-Downloadseite prüfen. Für ein Heimnetz ist das in der Praxis selten nötig.

Ab Home Assistant 2026.8 läuft eine neue HAOS-Installation standardmäßig auf Port 80, nicht mehr auf dem bisherigen Port 8123. Wer also nach der Installation homeassistant.local im Browser öffnet, landet direkt auf der HA-Oberfläche ohne Portangabe.

Ressourcen: Was HAOS wirklich braucht

Die Standardwerte des Community-Skripts (2 Kerne, 4 GB RAM, 32 GB Disk) sind ein guter Ausgangspunkt und für die meisten Setups ausreichend. Hier eine realistischere Einschätzung:

RessourceMinimumEmpfehlungWann mehr
CPU-Kerne22Frigate, viele Automationen gleichzeitig
RAM2 GB4 GBMit 5+ Add-ons, Frigate, großer Datenbank
Disk32 GB32-64 GBKamera-Aufzeichnung, langer Datenbank-History
HAOS selbst braucht im Betrieb mit wenigen Add-ons etwa 1,8 bis 2,2 GB RAM. Mit einer voll ausgebauten Installation mit Zigbee2MQTT, Mosquitto, Node-RED und ESPHome landet man bei 2,5 bis 3 GB. Frigate für Kamera-KI-Erkennung ist ein Sonderfall: Es profitiert von einer dedizierten GPU oder einem Google Coral USB-Beschleuniger.

Beim CPU-Modell in der Proxmox-VM-Konfiguration lohnt sich "Host" statt "kvm64", wenn Proxmox auf dediziertert Hardware läuft und keine Live-Migration auf andere Hosts geplant ist. "Host" gibt der VM Zugriff auf alle CPU-Features des Hosts, was bei manchen Workloads einen Unterschied macht.

Disk-Cache auf "Write Through" statt "None" ist sinnvoll. Es verhindert Datenverlust bei Stromausfällen auf Kosten von etwas Schreib-Performance, die bei einer Heimautomatisierung keine Rolle spielt.

USB-Passthrough für Zigbee- und Z-Wave-Sticks

Das ist der Teil, bei dem die meisten Probleme auftauchen. Nicht weil Proxmox es schwierig macht, sondern weil Linux-Gerätepfade weniger stabil sind als man denkt.

Das Problem mit ttyACM0: Wenn man einen Zigbee-Stick an einen USB-Port steckt, bekommt er einen Gerätepfad wie /dev/ttyACM0 oder /dev/ttyUSB0. Diese Nummer ist nicht fest. Wenn beim nächsten Neustart eine andere USB-Reihenfolge vorliegt, weil ein zweiter Stick angeschlossen wurde oder der Kernel die Geräte in anderer Reihenfolge initialisiert, bekommt derselbe Stick plötzlich /dev/ttyACM1. Zigbee2MQTT findet den Stick nicht mehr und meldet "Error: Failure to connect". Die Lösung: Vendor- und Device-ID-Passthrough. Statt einen USB-Port durchzureichen, reicht man das spezifische Gerät über seine Hersteller- und Produkt-ID durch. Die ID bleibt konstant, egal an welchem Port der Stick steckt.

Erst einmal die ID des Sticks auf dem Proxmox-Host ermitteln:

lsusb

Beispielausgabe für einen Sonoff ZBDongle-E:

Bus 001 Device 004: ID 1a86:55d4 QinHeng Electronics SONOFF Zigbee 3.0 USB Dongle Plus V2

Die relevante ID ist 1a86:55d4. In der Proxmox-Weboberfläche: VM auswählen, dann Hardware, dann Add, dann USB Device, dann nach Vendor/Device-ID suchen. Alternativ direkt über die Shell:

qm set 100 -usb0 host=1a86:55d4

Dabei ist 100 die VM-ID der HAOS-Installation. Nach dem nächsten VM-Start erscheint der Stick in Home Assistant unter Einstellungen, Geräte und Dienste als neues Gerät.

Die by-id-Lösung in HA selbst: Auch innerhalb von Home Assistant oder Zigbee2MQTT sollte man den Gerätepfad über /dev/serial/by-id/ angeben, nicht über /dev/ttyACM0. Die by-id-Symlinks sind stabil über Neustarts. Den richtigen Pfad zeigt: 
ls -la /dev/serial/by-id/

Ein typischer Pfad für den ZBDongle-E sieht so aus:

/dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20230509152410-if00

Wer diesen Pfad in der Zigbee2MQTT-Konfiguration einträgt, hat keine Überraschungen mehr nach Neustarts.

Eine bekannte Einschränkung beim LXC-Ansatz: Im Proxmox-Forum und in der Home-Assistant-Community gibt es mehrere Berichte darüber, dass das Gerät /dev/serial/by-id/ im Container nicht existiert, obwohl der Stick auf dem Host sichtbar ist. Das passiert, wenn udev im Container nicht korrekt konfiguriert ist. In einer VM mit HAOS tritt dieses Problem nicht auf, weil die VM ihre eigene udev-Instanz betreibt.

Snapshots und Backups: Der eigentliche Grund für Proxmox

Wer Home Assistant auf einem Raspberry Pi betreibt, kann zwar HA-eigene Backups erstellen, die die Konfiguration, Automationen und Add-on-Einstellungen sichern. Was fehlt: Ein Snapshot des Gesamtsystems, der in zehn Sekunden gezogen und in zwei Minuten wieder hergestellt ist.

Proxmox hat Snapshots eingebaut. Ein VM-Snapshot friert den aktuellen Zustand ein, inklusive RAM, CPU-Zustand und Disk-Inhalt. Anlegen geht über die Weboberfläche oder per Shell:

qm snapshot 100 vor-update-2026-8 --description "Vor HA 2026.8 Update"

Zurückrollen:

qm rollback 100 vor-update-2026-8

Das dauert weniger als eine Minute. Wer schon einmal nach einem fehlgeschlagenen HA-Update zwei Stunden mit SD-Karte neuschreiben verbracht hat, weiß, was das wert ist.

Snapshots ersetzen keine Backups. Ein Snapshot liegt auf demselben Speichermedium wie die VM. Geht die Disk kaputt, sind Snapshot und VM weg. Für echte Datensicherheit braucht man Backups, die auf einem anderen Gerät landen.

Proxmox Backup Server (PBS) kann auf einem NAS oder einem zweiten Rechner laufen und die HAOS-VM nachts sichern, mit Deduplizierung. Eine vollständige HAOS-VM mit 32 GB Disk, davon etwa 5-8 GB belegt, lässt sich in rund drei Minuten auf PBS sichern und in ähnlicher Zeit wiederherstellen.

Die sinnvolle Strategie ist zweilagig:

  • Proxmox-Snapshots vor jedem HA-Update und vor größeren Konfigurationsänderungen. Nach einer Woche stabilen Betriebs löschen.
  • Proxmox-Backups auf NAS oder PBS täglich, mit mindestens sieben Tagen Aufbewahrung. Zusätzlich: HA-eigene Backups in die Nabu-Casa-Cloud oder auf einen Netzwerkspeicher.
Wer beides hat, kann sich aus fast jeder Situation retten.

Die ehrliche Frage: Wer braucht das nicht

Proxmox mit HAOS-VM ist ein gutes Setup, aber es ist auch ein vollständiger Heimserver-Betrieb. Wer einrichten will, muss Proxmox installieren, sich mit Netzwerk-Konfiguration auseinandersetzen, verwalten, updaten. Das kostet Zeit, und die Zeit zahlt sich erst aus, wenn man mehrere Dienste betreibt oder HA so wichtig ist, dass man schnelle Rollbacks braucht.

Wer ausschließlich Home Assistant betreiben will, ohne weitere Dienste, und wem ein gelegentlicher Neustart nicht stört, ist mit einem Raspberry Pi 5 oder einem dedizierten HA-Gerät wie dem Home Assistant Green oder dem Home Assistant Yellow besser dran. Diese Geräte sind kompakter, verbrauchen weniger Strom und erfordern keine Proxmox-Kenntnisse.

Ein Raspberry Pi 5 mit 4 GB RAM und einer schnellen microSD oder einem SSD-Adapter läuft HAOS zuverlässig, solange man keine Dienste wie Frigate parallel betreibt. Der Green ist ähnlich aufgestellt, aber mit eMMC-Speicher, der SD-Kartenproblemen aus dem Weg geht.

Proxmox lohnt sich, wenn:

  • Man andere Dienste auf derselben Hardware betreiben will (NAS-Software, VPN, weitere VMs)
  • Schnelle Rollbacks bei HA-Updates wichtig sind
  • Man ohnehin Proxmox-Erfahrung hat oder aufbauen will
  • Hardware vorhanden ist, die mehr als einen Dienst verträgt

Schritt für Schritt: Was die Installation konkret bedeutet

Für jemanden, der Proxmox bereits installiert hat, läuft die HAOS-Installation so ab:

  1. Proxmox-Weboberfläche öffnen, Shell-Terminal starten
  2. Community-Skript ausführen (Befehl oben)
  3. Im Dialog entweder Standardwerte bestätigen oder eigene Werte für CPU, RAM, Disk angeben
  4. Warten, bis das Skript HAOS heruntergeladen, importiert und die VM gestartet hat (zwei bis fünf Minuten je nach Internetanbindung)
  5. Im Browser homeassistant.local oder die angezeigte IP-Adresse öffnen
  6. HA-Einrichtungsassistent durchlaufen
  7. Zigbee-Stick anschließen, USB-Passthrough in Proxmox konfigurieren, Stick in HA einrichten
Für Proxmox selbst gibt es das Post-Install-Skript aus demselben Community-Repository, das unter anderem die Enterprise-Repository-Warnung entfernt und das System aktualisiert: 
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

Den Hostnamen von Proxmox sollte man bei der Installation sorgfältig wählen. Er lässt sich später nicht einfach ändern, ohne dass Proxmox ernsthafte Probleme bekommt.

Quellen: