Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

[CoolTux]

Falls noch nicht geschehen, die Option discard anhaken, dann wird gelöschter Speicher auch wieder im Pool freigegeben.

Sofern das Filesystem von HASO das auch unterstützt. Nehmen die da ZFS?

 

[Falk R.]

Die nutzen gar kein BSD mehr, sondern buildroot um flexibler die verscheidenen Platformen zu unterstützen.
Aber als FS kommt ext4 zum Einsatz und das kann TRIMM, also mit der discard Option umgehen.

 

[CoolTux]

Mit ext4 ist doch sogar das verkleinern relativ problemlos möglich. Müsste man mal schauen wie die Partitionierung genau ist.

Aber Falk hat Recht, eigentlich ist es nur ein kosmetisches Ding.

 

[Falk R.]

Ich würde am HAOS nicht so viel basteln, da er z.B. zwei Partitionen für den Kernel und zwei für das OS hat. Die machen A/B switch bei Updates.

 

[lethuer]

Falls noch nicht geschehen, die Option discard anhaken, dann wird gelöschter Speicher auch wieder im Pool freigegeben.

Top Hinweis ! Hatte ich aber schon gemacht

 

[lethuer]

Moin !

Ich hatte leider wieder das Problem, dass mein "local" voll war.

Mit

root@proxmox:~# journalctl --disk-usage

habe ich dieses mal das hier bekommen:

Journal file /var/log/journal/27a75f85666348ada3dad0aff5ce8b9a/system.journal is truncated, ignoring file.

Trotzdem habe ich dann mit

journalctl --vacuum-size 1G

das System "local" dann wieder von rund 30GB auf 6.1GB reduzieren können.

Wie bekomme ich genauer raus was da jedes mal mit der Zeit den log Ordner voll müllt ?
Kann mich da jemand genauer anleiten und evtl. irgendwie nach der Ursache forschen ?


Auch bei meinen beiden LXC Containern hatte ich danach noch geschaut und gesehen, dass die "Bootdisk Größe" rot war.
Hier habe ich dann eben falls 15.2GB beim ersten bzw. 8.2GB beim zweiten Container frei machen können.
Beide melden aber ebenfalls:

Journal file /var/log/journal/a55811e5e7dd471c8828522cf3772105/system.journal is truncated, ignoring file.

bzw.

Journal file /var/log/journal/b63388389bb241bc9e5317b71cd5ae20/system.journal is truncated, ignoring file.

Was heißt das?

 

[lethuer]

Ich hatte leider wieder das Problem, dass mein "local" voll war...
Und wieder führte das dazu, dass nach einem Stromausfall nix mehr ging.
Erst gingen Zigbee Geräte nicht mehr, dann war kein Reboot mehr möglich.

Wer kann mir helfen herauszufinden warum „local“ immer voll läuft ??

 

[noPa$$word]

Wenn du wieder Zugriff auf die Konsole hast, würde ich zB mit

du -sh * | sort -hr

die Order der Größe nach anzeigen lassen. Danach kann man schauen, welche Dateien darin erstellt sind und hat so ev. einen Rückschluss wer sie produziert bzw woher sie kommen.

Ev. noch ncdu installieren und mit diesem Programm schauen.

apt install ncdu

 

[lethuer]

Ich musste halt mal wieder mit

journalctl --vacuum-size 1G

den log Ordner leer machen. Danach lief dann wieder alles.

Also das was voll ist ist der Journal Ordner, das weiß ich ja schon…
Nur weiß ich eben nicht warum.
Post in thread 'Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar'
https://forum.proxmox.com/threads/p...fall-nicht-mehr-erreichbar.150913/post-683158

In der datei /etc/systemd/journald.conf steht mittlerweile auch SystemMaxUse = 750M
Ich verstehe daher nicht wieso der ordner /var/log/journalüberhaupt volllaufen kann…

 

[lethuer]

Und gerade habe ich noch ein backup problem bei den containern (VM geht)
Und auf der Backup Platte ist auch platz…

INFO: starting new backup job: vzdump --compress zstd --mode snapshot --mailnotification always --storage Backup --notes-template '{{guestname}}' --node proxmox --quiet 1 --prune-backups 'keep-daily=14' --all 1
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2025-11-23 00:00:03
INFO: status = running
INFO: CT Name: InfluxDB2
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
snapshot create failed: starting cleanup
no lock found trying to remove 'backup'  lock
ERROR: Backup of VM 100 failed - lvcreate snapshot 'pve/snap_vm-100-disk-0_vzdump' error:   Cannot create new thin volume, free space in thin pool pve/data reached threshold.

 

[Impact]

Du könntest so etwas probieren und zu sehen welcher Service am meisten loggt

journalctl --output=cat --output-fields=UNIT | grep ".service" | sort | uniq -c | sort -nr | head -n50

Generell hat das Journal aber ein Limit und sollte nicht voll laufen.
Für das andere Problem Teile bitte

lvs
pct fstrim 100
lvs

 

[lethuer]

Generell hat das Journal aber ein Limit und sollte nicht voll laufen.

Und das wird doch hier eingestellt oder bin ich falsch ?
/etc/systemd/journald.conf mit SystemMaxUse = 750M

journalctl --output=cat --output-fields=UNIT | grep ".service" | sort | uniq -c | sort -nr | head -n50

Für das andere Problem Teile bitte
lvs
pct fstrim 100
lvs

 

[Impact]

Und das wird doch hier eingestellt oder bin ich falsch

Ja, es gibt aber ein default

defaults to 10% ... capped to 4G

Die Logs sind gerade eh ziemlich leer. Was sagt das hier

df -hT
lvmconfig
lvs -a

Durch das doofe LVM Namenssystem, kann ich nicht beurteilen, welche der IDs CTs und welche VMs sind. Du kannst aber das mal lesen, und schauen ob du damit etwas Platz frei machen kannst.

 

[Bu66as]

Hallo @lethuer,

anhand deines Screenshots lässt sich der Backup-Fehler (reached threshold) gut erklären:

Du hast eine massive Überprovisionierung (Overprovisioning) vorliegen.Dein Speicher-Pool (data) ist physikalisch nur <80,24 GB groß.Du hast den VMs/Containern aber virtuellen Speicher von weit über 160 GB zugewiesen (allein vm-135-disk-1 ist mit 128 GB größer als dein ganzer Server-Speicher).

Der Pool ist real zu 70,13% gefüllt. Wenn du ein Backup im Modus "Snapshot" startest, benötigt LVM freien Platz im Pool, um Änderungen während des Backups zwischenzuspeichern. Da der Pool aber schon recht voll ist und rechnerisch völlig überbucht, verweigert Proxmox den Snapshot aus Sicherheitsgründen, um zu verhindern, dass der Pool vollläuft und alles abstürzt.

Lösungsschritte:

1. Backup-Modus: Stelle den Backup-Job temporär von "Snapshot" auf "Stop" um. Dabei wird der Container kurz heruntergefahren, es wird aber kein LVM-Snapshot-Platz benötigt. Das sollte funktionieren.
2. Warnung: Die 128 GB Disk auf dem 80 GB Speicher ist ein hohes Risiko. Wenn diese VM anfängt, den Platz wirklich zu nutzen, läuft dein Host voll (data auf 100%) und alle VMs bleiben stehen oder das Dateisystem wird read-only.
3. Logs/Root-Partition: Dein Screenshot zeigt nur die LVM-Ebene (lvs). Um das Problem mit dem vollen "local" Speicher (Logs) zu prüfen, fehlt noch die von @Impact angefragte Ausgabe von df -h. Nur dort sehen wir, wie voll / (pve-root) auf Dateisystem-Ebene wirklich ist.

Das fstrim Ergebnis (0 Bytes) bedeutet, dass im Container entweder kein Platz zum Freigeben gefunden wurde oder die Daten dort tatsächlich belegt sind.

 

[lethuer]

Ja, es gibt aber ein default

defaults to 10% ... capped to 4G
Dann bleibt die Frage warum der Journal Ordner immer wieder voll läuft…
Gerade sieht es aber gut aus (was es so schwierig macht)

Durch das doofe LVM Namenssystem, kann ich nicht beurteilen, welche der IDs CTs und welche VMs sind.

100 + 101 sind Container
135 ist VM

Du hast eine massive Überprovisionierung (Overprovisioning) vorliegen.Dein Speicher-Pool (data) ist physikalisch nur <80,24 GB groß.Du hast den VMs/Containern aber virtuellen Speicher von weit über 160 GB zugewiesen (allein vm-135-disk-1 ist mit 128 GB größer als dein ganzer Server-Speicher).

Warnung: Die 128 GB Disk auf dem 80 GB Speicher ist ein hohes Risiko. Wenn diese VM anfängt, den Platz wirklich zu nutzen, läuft dein Host voll (data auf 100%) und alle VMs bleiben stehen oder das Dateisystem wird read-only.

Jap leider hab ich das bei der Einrichtung nicht beachtet.
Für die Container hatte ich den zugewiesenen Speicher sogar bereits reduziert…

L

Post in thread 'Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar'

Jul 13, 2024

Du hast dein Storage überprovisioniert (ist mit lvm-thin möglich). Deine sda3 Partition/local-lvm, wo deine LXC/VM Daten liegen hat ~118G an Kapazität.
Du hast aber mehr zugewiesen:

verstehe. ich konnte die größe der beiden lxc mit dieser anleitung verkleinern:
https://tfta.de/forum/thread/7-proxmox-ve-verkleinern-einer-lvm-basierten-festplatte/

aber für die VM hat das leider nicht geklappt... gibt es hier eine anleitung wie ich die vm verkleinern könnte ?

• lethuer

Die scheinen mit 25G (100) + 10G (101) nun aber eigentlich zu knapp bemessen, da beide so gut wie voll.
Hab ihnen also wieder etwas mehr Speicher zuweisen müssen (jetzt 35G bzw. 15G).

Aber anscheinend gibt es keine sinnvolle Möglichkeit den zugewiesenen Speicher der VM nachträglich zu reduzieren?
Meine HomeAssistant Oberfläche (die auf 135 läuft) sagt mir aber sie wäre nur zu 26% belegt und hätte noch 86G frei.
Kommt ja fast hin mit den zugewiesenen 128G, die könnte also deutlich kleiner werden (z.B. 50G).
Insgesamt ist die Platte aber wohl einfach zu klein…

 

[lethuer]

Die Logs sind gerade eh ziemlich leer.

So sieht es heute aus


Was sagt das hier

df -hT
lvmconfig

Logs/Root-Partition: Dein Screenshot zeigt nur die LVM-Ebene (lvs). Um das Problem mit dem vollen "local" Speicher (Logs) zu prüfen, fehlt noch die von @Impact angefragte Ausgabe von df -h. Nur dort sehen wir, wie voll / (pve-root) auf Dateisystem-Ebene wirklich ist.

lvs -a

 

[lethuer]

Backup-Modus: Stelle den Backup-Job temporär von "Snapshot" auf "Stop" um. Dabei wird der Container kurz heruntergefahren, es wird aber kein LVM-Snapshot-Platz benötigt. Das sollte funktionieren.

Tatsächlich funktioniert das Backup aktuell mit allen VM und Containern auch auf „Snapshot“ (ich hab aber nichts geändert).

Irgendwie finde ich den Backup Job für die einzelnen Maschinen nicht..
Wo könnte ich das im Zweifel umstellen ?