Home Assistant (HA) - VM beendet sich von selbst

  • also erst einmal ist hier kein heiteres Containerraten! WEnn Du etwas wissen willst, dann musst Du auch Informationen bieten. Wenn Dein Immich in der VM im Docker läuft dann:
    VM Layer1 Docker Layer2 Immich Anweisungen Layer3 ---> crash

    Warum ein Container wie Immich den Host/die VM crashen kann

    Auch wenn Container isoliert wirken, teilen sie sich denselben Linux-Kernel mit dem System, auf dem sie laufen (in deinem Fall mit der VM).

    Wenn Docker innerhalb des Containers angewiesen wird, eine Aktion auszuführen, die neue Dateisystem-Schichten benötigt, bittet Docker den Kernel der VM, diese Schichten bereitzustellen. Wenn dieser Kernel dann feststellt, dass das Limit von 2 Schichten überschritten wird, blockiert er die Operation global. Das führt zu Fehlern in dmesg und kann die gesamte VM instabil machen oder einfrieren lassen.


    Warum packst Du immich nicht in Docker des NAS?
    Wenn Immich so auf dem NAS direkt auf in einem Docker Container läuft und es dann crasht, dann kann es auch daran liegen, dass Du den RAM so auslastest, dass der Kernel irgendwann Panik schiebt und schaut was grad nicht genutzt wird und killt das. Das könnte dann Deine VM sein.
    Da ich kein ugreenOS Entwickler bin kann ich Dir nicht sagen was verändert wurde und ob etwas verändert wurde. In meinem Beruf erlebe ich immer wieder dass auf ein Update geschimpft wird, nur weil ein zeitlicher Zusammenhang zwischen dem Update und dem Problem besteht. Dabei hat das Problem gar keinen kausalen Zusammenhang mit dem Update.
    Und ehrlich gesagt, möchte ich hier nicht weiter ewig lange Hinweise und Tutorials schreiben wie man die Ursachen finden kann. Das Thema ist zu kompliziert um es per Forum zu lösen. Vielleicht versucht ihr es mal beim ugreen Support.
    Über jedes Stöckchen (Vermutung ohne Fakten aus logs) zu springen hilft hier keinem weiter. Es stiehlt uns beiden nur Zeit!

    Sorry, aber nach den ganzen Hinweisen zur Lösung die ich gegeben habe, bin ich erst einmal raus.

    Signatur ...

    DXP4800Pro
    Windows | Linux | Android | iOS
    Github

  • steffenglock sorry....du hast vollkommen Recht

    Vielen Dank für deine Geduld und ausführliche Hilfe.
    Könntest du mir bitte noch sagen ob meine Vorgehensweise richtig/sinnvoll ist?

    In UGOS habe ich die Apps Virtual Machine und Docker installiert.
    In der Virtual Machine habe ich eine VM homeassistant angelegt und dort HAOS installiert. In dieser Homeassistant Instanz ist auch Adguard als App installiert. Der VM habe ich 2 Kerne, 12 GB RAM und 100GB SSD zugewiesen. Es ist keine weitere VM installiert.

    In Docker habe ich nur die 4 Container von Immich, sonst nicht weiter. Hier habe ich nichts gefunden wo ich den RAM begrenzen kann.
    Insgesamt sind 32GB RAM im NAS. Virtual Machine und Docker sind auf einer 1TB NVMe installiert.

    Ich bin so vorgegangen, weil ich es nicht besser wusste und die meisten Tuts es so zeigen.

  • Wenn du mal Adguard aus der VM rausnimmst und als eigenständigen Docker Container laufen lässt? 🤔

    DXP4800PLUS mit 3x 8TB (2xWD, 1x Seagate),1x 512GB SSD, 2TB NVM SSD, 8GB + 32GB RAM

  • Hier habe ich nichts gefunden wo ich den RAM begrenzen kann

    Das mußt Du bereits in die yaml mit aufnehmen.

    Meine Hardware

    iDX6011 Pro (64GB RAM) btrfs, 2x12 TB SG Enterpr. Raid1, 1x12TB SG Enterpr. Basic, 2x 2TB NVME Lexar NM790 Raid1,

    DXP2800 btrfs 1x 12TB WDRedPl, 16GB RAM Crucial CT16G56C46S5.C8B2, NVME 2x 500GB Samsg. 970 EVOPlus Raid1,

    DS1525+, btrfs 2x8TB WD, btrfs SHR, 1x 12 TB SG IronWolf, 1x 3TB WD RedPlus, 2x 2TB NVME Lexar NM790 Raid1, 40GB ECC RAM

    DS218+ btrfs 1x12TB WD, 1x SSD 500GB, RAM 20GB DDR4-2666MHZ

    USV US3000, EatonEllip.PRO 850DIN, Zyxel XMG-108 8 x 2,5GB, Zyxel GS1200-8 x 1GB,

  • n dieser Homeassistant Instanz ist auch Adguard als App installiert.

    alles gut!

    soweit alles gut nur Adguard würde ich nicht in der HomeAssistant App installieren, da die ein neues Overlay bedeutet. Das würde ich nativ auf dem NAS in der Docker-Umgebung laufen lassen. Meiner Meinung nach müsste HomeAssistant in der VM mit 2 Kernen und max 8GB RAM auskommen. Das kannst Du ja in der VM einstellen.
    Die Installation von Docker auf der NVMe ist sehr sinnvoll! Ich habe hier über 20 Container in Docker und HA in der VM mit 4GB RAM laufen und das Flutscht. Insgesammt habe ich 16GB RAM auf meinem NAS.
    Wenn man HAS noch zusätzlich beschleunigen will, dann sollte man einige Dauerplauderer bei den Entitäten auf vielleicht 2-3 Tage Datensammlung beschränken.
    Ich pack Dir hier mal noch etwas als Spoiler rein sonst wird es zu unübersichtlich:

    Display Spoiler

    Sinnvolle Entitäten zum Ausschließen oder Begrenzen

    1. Die "Dauerplauderer" (Häufige Updates)

    Manche Sensoren senden sekündlich neue Werte, die den Recorder extrem aufblähen, deren Verlauf man aber selten rückwirkend braucht:

    • Leistungsmesser (Watt): Smarte Steckdosen oder Stromzähler (sensor.power_*), die jede minimale Schwankung protokollieren.
    • System-Metriken: CPU-Auslastung, freier RAM, Festplattenplatz oder die Uptime von Home Assistant (sensor.processor_use, sensor.memory_free, etc.).
    • Signalstärken (RSSI / Linkquality): Zigbee- oder WLAN-Verbindungsqualitäten (sensor.*_rssi oder sensor.*_linkquality). Diese ändern sich ständig, ohne echten Mehrwert im Verlauf.

    2. Entitäten mit großen Datenmengen (Attribute)

    Einige Entitäten speichern riesige Textmengen oder Arrays in ihren Attributen. Jede Änderung schreibt diesen riesigen Block erneut in die Datenbank:

    • Wetter-Entitäten (weather.*): Diese enthalten oft die Vorhersagen für die nächsten 10 Tage als massives Datenpaket.
    • Update-Entitäten (update.*): Sie prüfen nur, ob Software-Updates bereitstehen. Ein Verlauf ist hier völlig überflüssig.
    • Sonne (sun.sun): Ändert minütlich das Azimut und die Elevation. Das lässt sich mathematisch berechnen und muss nicht die DB verstopfen.

    3. Ganze Domänen (Hintergrundprozesse)

    Wenn du nicht zwingend im Logbuch nachvollziehen musst, wann sekundengenau jede Automatisierung lief, kannst du ganze Bereiche ausschließen:

    • automation und script: Verbrauchen viel Platz, wenn du viele im Hintergrund laufen hast.
    • zone und device_tracker: Wenn du kein Bewegungsprofil deiner Geräte brauchst.

    Wichtiger Hinweis zu Langzeit-Statistiken

    Quote

    ⚠️ Keine Angst um das Energie-Dashboard: Home Assistant trennt die normale Historie (Recorder) von den sogenannten Langzeit-Statistiken (LTS). Wenn du purge_keep_days auf 3 Tage stellst, bleiben deine stündlichen/täglichen Verbrauchswerte im Energie-Dashboard trotzdem dauerhaft erhalten. Das gilt für alle Sensoren mit der Eigenschaft state_class: total_increasing oder measurement.

    Praxis-Beispiel für deine configuration.yaml

    So könnte deine Konfiguration aussehen, um die globale Vorhaltezeit auf 3 Tage zu reduzieren und den "Spam" komplett zu blockieren:

    YAML


    Nach dem Eintragen musst du Home Assistant einmal neu starten. Die Datenbank wird sich danach nicht sofort verkleinern, aber beim nächsten nächtlichen Bereinigungslauf (Purge) wird aufgeräumt.

    ch bin so vorgegangen, weil ich es nicht besser wusste und die meisten Tuts es so zeigen.

    DAs ist auch OK so lange HA auf einem eigenen Server wie einem Raspi läuft. Auf einem NAS teilt man sich halt den RAM mit vielen anderen Prozessen. Da heißt es leider "lernen durch Schmerz". So lange alles läuft kommt man ja auch nicht auf die Idee, dass es bessere Konfigurationen ohne Komfortverlust gibt.

    Signatur ...

    DXP4800Pro
    Windows | Linux | Android | iOS
    Github

  • So hier vielleicht noch einen Hinweis für alle die ihr HA etwas optimieren wollen.

    Installiert Euch über den HACS die App HAGHS.

    Dann erstellt ihr euch eine Kachel im Dashboard mit folgendem Inhalt:

    Das erzeugt euch eine schöne Kachel mit einigen Hinweisen bis hin zu Zombi Entitäten in eurem System und dann könnt ihr ja aufräumen. Entitäten die ihr noch braucht die aber als Zombie identifiziert werden weil sie vielleicht vorübergehend nicht erreichbar sind könnt ihr mit dem Label haghs_ignore versehen. Dann wird es nicht mehr aufgezählt.

    Signatur ...

    DXP4800Pro
    Windows | Linux | Android | iOS
    Github

  • vielen Dank dafür

    ich werde den Rat mit AdGuard auslagern bei nächster Gelegenheit umsetzen. Ich fand es schick, direkt über HA bedienen und kontrollieren zu können.

    Das System lief so auch auf einem RPi5 mit SSD und 8GB Ram über Jahre problemlos. HAGHS ist mir auch bekannt und benutze ich seit einigen Wochen. Mein Score ist 94...und auch nur deshalb, weil ein paar meiner Geräte (zB. 3D Drucker) nicht ständig online sind.
    Die VM zeigt mir im Übrigen eine RAM Nutzung um 6GB (von 12) an. Selbst wenn ich mir Videos der Überwachungs-Kameras anschaue...alles flüssig und schnell und die RAM Nutzung steigt nicht an.

    In meinem HA sind 41 Intergrationen, Grafana, InfluxDB...das übliche halt.

    Den Recorder Eintrag in die configuration.yaml habe ich sofort umgesetzt....auch dafür vielen Dank

    btw. ich wollte nicht das Update oder die Arbeit von Ugreen schlecht machen, es kam mir nur komisch vor, daß mein System vor dem Update eine Woche stabil lief. Immich hat 1,2TB Bilder geladen und bearbeitet...ohne Probleme oder das die VM oder was anderes sich ausgeschalten hat.
    Der Prozessor war zwar ab und an auf 100% aber RAM Auslastung in Spitzen nur bei 70%, max Temperatur bei 70 Grad.

  • ich habe neue Erkenntnisse:

    overlayfs: maximum fs stacking depth exceeded wird von Docker/Immich ausgelöst
    ich habe die VM stillgelegt und Immich im docker so eingestellt, daß es nicht automatisch startet.

    Die Speicherbrgrenzung für Immich habe ich in der yml konfiguriert und den RAM für die Homeassistant VM habe ich wieder auf 8Gb eingestellt.

    Dann habe ich die DXP4800GT neu gestartet und dmesg ausgeführt.
    > keine Fehlermeldungen
    VM gestartet und dmesg ausgeführt
    > keine Fehlermeldungen
    VM wieder aus, neu NAS neu gestartet, Docker Immich gestartet, VM ist immer noch aus und dmesg
    > overlayfs: maximum fs stacking depth exceeded erscheint wieder

    das kommt also nicht von der VM, meiner Meinung nach

    auf meinem RAID5 Volume ist ein Ordner mit >80000 Bildern. Diesen Ordner habe ich in Immich als ext. Quelle angelegt.
    In diesem Ordner sind viele Unterordner mit Unterordner usw.

    kann dies auch overlayfs: maximum fs stacking depth exceeded erzeugen?

Participate now!

Join our community with over 10,000 members!

Register yourself now for free to get full access to all content, graphics, downloads and other exclusive features!