Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

UdoB · Jul 11, 2024

lethuer said:
was wären denn sinnhafte werte ? SystemMaxUse = 800 ?

Keine Ahnung. Mein Beispiel ist nur ein Beispiel = keine Empfehlung.

Solange die Platte nicht voll läuft ;-) würde ich den Entwicklern vertrauen und den Default einfach unverändert beibehalten. Bei den meisten meiner kleinen System liegt die aktuelle Größe unter 3GB.

Manchmal sind relativ alte Logs ja sehr wohl hilfreich. journalctl | head zeigt dir die ältesten Einträge.

lethuer · Jul 11, 2024

lethuer said:
Aber die zwei Container werden irgendwie noch nicht gestartet ?

"Konfiguration gesperrt (fstrim)"

das hat geholfen:

Code:

root@proxmox:~# pct unlock 100
root@proxmox:~# pct unlock 101

für eine vm wäre es das gewesen:

Code:

qm unlock ID

lethuer · Jul 11, 2024

nun stelle ich in den backups fest, dass bereits seit dem 28.05. kein automatisches backup mehr erstellt wurde....

außerdem scheinen die beiden container ziemlich voll zu sein:

wie kann ich hier altlasten löschen ?
beide haben 48G "Root-Disk" Größe

wieso haben beide container exakt die gleiche disk auslastung ?

beim versuch manuell ein backup eines containers anzustoßen bekomme ich diese warning:

Code:

INFO: starting new backup job: vzdump 101 --mode snapshot --storage Backup --node proxmox --remove 0 --notes-template '{{guestname}}' --compress zstd
INFO: Starting Backup of VM 101 (lxc)
INFO: Backup started at 2024-07-11 16:58:41
INFO: status = running
INFO: CT Name: Grafana
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
  Logical volume "snap_vm-101-disk-0_vzdump" created.
  WARNING: Sum of all thin volume sizes (272.00 GiB) exceeds the size of thin pool pve/data and the size of whole volume group (<118.74 GiB).
INFO: creating vzdump archive '/mnt/pve/Backup/dump/vzdump-lxc-101-2024_07_11-16_58_41.tar.zst'

die aktuelle übersicht des speichers:

Code:

root@proxmox:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
udev                  3.8G     0  3.8G   0% /dev
tmpfs                 783M  1.2M  782M   1% /run
/dev/mapper/pve-root   29G  6.9G   21G  26% /
tmpfs                 3.9G   46M  3.8G   2% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
/dev/sda2             511M  328K  511M   1% /boot/efi
/dev/sdb1             916G  215G  656G  25% /mnt/pve/Backup
/dev/fuse             128M   16K  128M   1% /etc/pve
tmpfs                 783M     0  783M   0% /run/user/0
root@proxmox:~# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 119.2G  0 disk
├─sda1                         8:1    0  1007K  0 part
├─sda2                         8:2    0   512M  0 part /boot/efi
└─sda3                         8:3    0 118.7G  0 part
  ├─pve-swap                 253:0    0     7G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0  29.5G  0 lvm  /
  ├─pve-data_tmeta           253:2    0     1G  0 lvm
  │ └─pve-data-tpool         253:4    0  80.2G  0 lvm
  │   ├─pve-data             253:5    0  80.2G  1 lvm
  │   ├─pve-vm--135--disk--0 253:6    0     4M  0 lvm
  │   ├─pve-vm--135--disk--1 253:7    0   128G  0 lvm
  │   ├─pve-vm--100--disk--0 253:8    0    48G  0 lvm
  │   └─pve-vm--101--disk--0 253:9    0    48G  0 lvm
  └─pve-data_tdata           253:3    0  80.2G  0 lvm
    └─pve-data-tpool         253:4    0  80.2G  0 lvm
      ├─pve-data             253:5    0  80.2G  1 lvm
      ├─pve-vm--135--disk--0 253:6    0     4M  0 lvm
      ├─pve-vm--135--disk--1 253:7    0   128G  0 lvm
      ├─pve-vm--100--disk--0 253:8    0    48G  0 lvm
      └─pve-vm--101--disk--0 253:9    0    48G  0 lvm
sdb                            8:16   0 931.5G  0 disk
└─sdb1                         8:17   0 931.5G  0 part /mnt/pve/Backup

Ernst T. · Jul 11, 2024

lethuer said:
wie kann ich hier altlasten löschen ?

Ich würde da auch mal die Größen der Logfiles checken, und dann einen "vacuum-size" machen, falls es an den Logs liegt.

Mich würde die knapp 100% CPU Auslastung aber auch stören.

lethuer · Jul 11, 2024

Ernst T. said:
Mich würde die knapp 100% CPU Auslastung aber auch stören.

die war nach einem reboot weg...

Ernst T. said:
Ich würde da auch mal die Größen der Logfiles checken, und dann einen "vacuum-size" machen, falls es an den Logs liegt.

wie finde ich die ?

das oben genutzt kommando erzählt mir nichts darüber wo 48G zu finden sein sollen....

Code:

root@proxmox:~# du -h -x -d1 /
243M    /boot
2.5G    /var
3.3G    /usr
4.0K    /home
12K     /mnt
4.0K    /srv
16K     /lost+found
40K     /tmp
1003M   /root
4.0K    /media
4.0K    /opt
5.0M    /etc
6.9G    /

Ernst T. · Jul 11, 2024

lethuer said:
wie finde ich die ?

Genauso so wie du das am Host schon gemacht hast, jetzt in den LXCs auch nochmal:

journalctl --disk-usage und zB journalctl --vacuum-size 100M

lethuer · Jul 11, 2024

Ernst T. said:
Genauso so wie du das am Host schon gemacht hast, jetzt in den LXCs auch nochmal:

vielleicht bin ich blind... aber ich bin als root mit putty auf dem proxmox server und sehe einfach nicht wo ich hin navigieren muss...
die schwierigkeit besteht darin in die konsole der lxc zu kommen...

wenn ich das jetzt aber in der konsole der web ui mache bekomme ich:

Code:

root@InfluxDB2:~# journalctl --disk-usage
Journal file /var/log/journal/a55811e5e7dd471c8828522cf3772105/system.journal is truncated, ignoring file.
Archived and active journals take up 37.5G in the file system.

und

Code:

root@Grafana:~# journalctl --disk-usage
Journal file /var/log/journal/b63388389bb241bc9e5317b71cd5ae20/system.journal is truncated, ignoring file.
Archived and active journals take up 44.1G in the file system.

nach journalctl --vacuum-size 100M

Code:

root@InfluxDB2:~# journalctl --disk-usage
Journal file /var/log/journal/a55811e5e7dd471c8828522cf3772105/system.journal is truncated, ignoring file.
Archived and active journals take up 96.0M in the file system.

bzw.

Code:

root@Grafana:~# journalctl --disk-usage
Journal file /var/log/journal/b63388389bb241bc9e5317b71cd5ae20/system.journal is truncated, ignoring file.
Archived and active journals take up 96.0M in the file system.
.

problem scheint damit fast gelöst.
wie kann ich denn verhindern, das in zukunft diese riesen massen an logs entstehen ?

bei manuellem backup bekomme ich immer noch diese warning:

Code:

INFO: starting new backup job: vzdump 100 --mode snapshot --storage Backup --node proxmox --remove 0 --compress zstd --notes-template '{{guestname}}'
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2024-07-11 18:40:37
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'
  Logical volume "snap_vm-100-disk-0_vzdump" created.
  WARNING: Sum of all thin volume sizes (272.00 GiB) exceeds the size of thin pool pve/data and the size of whole volume group (<118.74 GiB).
INFO: creating vzdump archive '/mnt/pve/Backup/dump/vzdump-lxc-100-2024_07_11-18_40_37.tar.zst'

Ernst T. · Jul 11, 2024

lethuer said:
wie kann ich denn verhindern, das in zukunft diese riesen massen an logs entstehen ?

1. Ursache für die Syslog-Einträge beheben.
2. Wie @UdoB schon geschrieben hat, die "SystemMaxUse = xxxM" ändern.

lethuer · Jul 11, 2024

Ernst T. said:
1. Ursache für die Syslog-Einträge beheben.

Da werd ich mal rein schauen was in den aktuellsten so drin steht die jetzt noch existieren…

Ernst T. said:
2. Wie @UdoB schon geschrieben hat, die "SystemMaxUse = xxxM" ändern.

Diese Angabe gilt aber pro log Datei wenn ich das richtig verstehe, oder ? Ich hatte ja nicht wirklich viele große log Dateien (nur ca 15 mehr als > 16Mb) wie sinnhaft ist es denn hier sehr kleine Werte einzugeben ? Beispielsweise sind die meisten log Dateien da 8Mb groß…

In jedem Falle vielen Dank an alle hier ! Super Support

Ernst T. · Jul 12, 2024

lethuer said:
Diese Angabe gilt aber pro log Datei

Nein. Das ist einfach die maximale Größe die der Ordner /var/log/journal/ erreichen muss, bevor das System im Journal automatisch zu löschen beginnt.

fluxX04 · Jul 12, 2024

lethuer said:
bei manuellem backup bekomme ich immer noch diese warning:

Das wird auch nicht verschwinden. Ist auch nur eine Warnung und weißt dich darauf hin, dass du das im Auge behalten musst.

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:

vm 135 ~128G
lxc 100 ~ 48G
lxc 101 ~ 48G

sind in Summe ~224G, was der Warnung entspricht.
Du musst nur aufpassen, dass das Storage am ProxmoxVE Node nich voll läuft (local-lvm), sonst könnte es zu Datenverlust bei deinen LXC's/VM's kommen, da die fröhlich weiterschreiben auf das Storage aber dieses voll ist.

Greetz

lethuer · Jul 13, 2024

Ernst T. said:
Nein. Das ist einfach die maximale Größe die der Ordner /var/log/journal/ erreichen muss, bevor das System im Journal automatisch zu löschen beginnt.

Danke ! Muss aber ebenfalls pro VM / LXC gemacht werden ? In der HomeAssistant VM finde ich diese jedenfalls nicht ?
In den beiden LXC schon und ebenfalls in der Proxmox Shell. Also habe ich jetzt "#SystemMaxUse=1000M" jeweils in "/etc/systemd/journald.conf" eingestellt.

lethuer · Jul 13, 2024

lethuer said:
Da werd ich mal rein schauen was in den aktuellsten so drin steht die jetzt noch existieren…

bei dem versuch bin ich leider ein wenig gescheitert...

der journal ordner hatte schon wieder 1.8G, also habe ich erneut auf 1G reduziert.

Code:

root@proxmox:/var/log/journal/27a75f85666348ada3dad0aff5ce8b9a# journalctl --disk-usage
Archived and active journals take up 1.0G in the file system.

das ist der inhalt des ordners:

Code:

root@proxmox:/var/log/journal/27a75f85666348ada3dad0aff5ce8b9a# ls -la
total 1057096
drwxr-sr-x+ 2 root systemd-journal   266240 Jul 13 20:43 .
drwxr-sr-x+ 3 root systemd-journal     4096 Nov 20  2022 ..
-rw-r-----+ 1 root systemd-journal  8388608 Jan 16 05:25 system@00060f0883dfac88-4f658087f6ae56c8.journal~
-rw-r-----+ 1 root systemd-journal  8388608 Jan 16 05:29 system@00060f0891d5774a-e610cfe1d1e0a876.journal~
-rw-r-----+ 1 root systemd-journal 58720256 May 28 00:06 system@00061976b930eb92-72fd07f890f8c482.journal~
-rw-r-----+ 1 root systemd-journal 75497472 Jan 31 18:19 system@0a9470f4e465487b8305efecd994b787-0000000000000001-00060f7a2b3696df.journal
-rw-r-----+ 1 root systemd-journal 75497472 Feb  7 09:47 system@0a9470f4e465487b8305efecd994b787-000000000000e7e4-000610411598b373.journal
-rw-r-----+ 1 root systemd-journal 75497472 Feb 14 01:17 system@0a9470f4e465487b8305efecd994b787-000000000001cb8e-000610c6bfb4a98a.journal
-rw-r-----+ 1 root systemd-journal 75497472 Feb 20 16:54 system@0a9470f4e465487b8305efecd994b787-000000000002af26-0006114c7081ba7c.journal
-rw-r-----+ 1 root systemd-journal 75497472 Feb 27 08:24 system@0a9470f4e465487b8305efecd994b787-00000000000392b5-000611d23a4f6a2b.journal
-rw-r-----+ 1 root systemd-journal 75497472 Mar  4 23:55 system@0a9470f4e465487b8305efecd994b787-000000000004764b-00061257ea5cd971.journal
-rw-r-----+ 1 root systemd-journal 75497472 Mar 11 15:23 system@0a9470f4e465487b8305efecd994b787-00000000000559d8-000612dda05dd618.journal
-rw-r-----+ 1 root systemd-journal 75497472 Mar 18 06:52 system@0a9470f4e465487b8305efecd994b787-0000000000063d6f-0006136348ab32bd.journal
-rw-r-----+ 1 root systemd-journal 75497472 Mar 24 22:26 system@0a9470f4e465487b8305efecd994b787-0000000000072104-000613e8f709cd60.journal
-rw-r-----+ 1 root systemd-journal 75497472 Mar 31 14:52 system@0a9470f4e465487b8305efecd994b787-000000000008049c-0006146eb5c28e6b.journal
-rw-r-----+ 1 root systemd-journal 75497472 Apr  7 06:18 system@0a9470f4e465487b8305efecd994b787-000000000008e82f-000614f45944c83e.journal
-rw-r-----+ 1 root systemd-journal 75497472 Apr 13 21:46 system@0a9470f4e465487b8305efecd994b787-000000000009cbcc-00061579f9b5072d.journal
-rw-r-----+ 1 root systemd-journal 83886080 May  2 11:40 system@0a9470f4e465487b8305efecd994b787-00000000000aaf62-000615ffa39f8588.journal
-rw-r-----+ 1 root systemd-journal 16777216 Jul 13 21:00 system.journal

ich sehe hier nicht mehr als diese dateien mit max ~80Mb. wie kommen denn hier 1G zustande ?

Code:

root@proxmox:/var/log/journal/27a75f85666348ada3dad0aff5ce8b9a# find . -type f -printf '%p %k\n' | sort -n  -k2
./system@00060f0883dfac88-4f658087f6ae56c8.journal~ 8192
./system@00060f0891d5774a-e610cfe1d1e0a876.journal~ 8192
./system.journal 16388
./system@00061976b930eb92-72fd07f890f8c482.journal~ 57348
./system@0a9470f4e465487b8305efecd994b787-0000000000000001-00060f7a2b3696df.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000000e7e4-000610411598b373.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000001cb8e-000610c6bfb4a98a.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000002af26-0006114c7081ba7c.journal 73732
./system@0a9470f4e465487b8305efecd994b787-00000000000392b5-000611d23a4f6a2b.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000004764b-00061257ea5cd971.journal 73732
./system@0a9470f4e465487b8305efecd994b787-00000000000559d8-000612dda05dd618.journal 73732
./system@0a9470f4e465487b8305efecd994b787-0000000000063d6f-0006136348ab32bd.journal 73732
./system@0a9470f4e465487b8305efecd994b787-0000000000072104-000613e8f709cd60.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000008049c-0006146eb5c28e6b.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000008e82f-000614f45944c83e.journal 73732
./system@0a9470f4e465487b8305efecd994b787-000000000009cbcc-00061579f9b5072d.journal 73732
./system@0a9470f4e465487b8305efecd994b787-00000000000aaf62-000615ffa39f8588.journal 81924

Hier der log von heute. Kann man dort was erkennen was die Ursache für die Syslog-Einträge sein könnte ?

lethuer · Jul 13, 2024

fluxX04 said:
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 · Sunday at 15:23

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

hat hier noch jemand hilfe ?
Meine HomeAssistant Installation hat noch ziemlich viel platz frei, daher würde ich gerne die VM verkleinern.

CoolTux · Monday at 15:03

Funktioniert im Grunde ähnlich. Nur das Du erstmal die Platte in der VM verkleinern musst. Also sowohl das Filesystem wie auch die Partition/en. Danach solltest Du das LV auf Hypervisor Ebene anpassen können.

Search

Search

Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

UdoB

Famous Member

lethuer

New Member

lethuer

New Member

Ernst T.

Renowned Member

lethuer

New Member

Ernst T.

Renowned Member

lethuer

New Member

Ernst T.

Renowned Member

lethuer

New Member

Ernst T.

Renowned Member

fluxX04

Renowned Member

lethuer

New Member

lethuer

New Member

Attachments

lethuer

New Member

lethuer

New Member

CoolTux

Famous Member