Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

[lethuer]

So neues Proxmox ist drauf mit zfs (RAID0) und unter Datecenter->pve->Updates alles installiert.
Das hat jetzt inkl. Wiederherstellung der Backups tatsächlich nur 2h gedauert und ich sollte wieder ein vernünftiges System haben...



Meine externe Platte habe ich neu eingebunden und das zuvor gezogene Backup der VM (HomeAssistant) + Container (InfluxDB) wiederhergestellt.

Für das Trimmen beim Container habe ich nano /etc/crontab wieder angepasst:


Das Trimmen der VM erfolgt ja nach wie vor über HomeAssistant selber


Das Wearout der neuen SSD wird ebenfalls angezeigt und liegt aktuell bei 0%


Einen neuen Proxmox Backup Job habe ich auch angelegt


Was sollte ich nun noch beachten und einstellen / überprüfen ?

 

[lethuer]

dann nimmst du das was dir bei der Installation vorgeschlagen wird.

dieses Bild kam bei der Installation.:

Das gibt es im Installer nicht als Option.

Da habe ich jetzt zfs (RAID0) gewählt.
Ich hoffe das war korrekt ?

 

[Impact]

Dein PVE war wohl zu alt für die Mount Option.

ist ja drin

Nicht mein Snippet. Deins ist spezifisch für bestimmte CT. Meines musst du nie wieder anfassen.

genau davon wurde doch abgeraten

Ich weiß, ich teile diese Meinung aber nicht. Mach deine eigenen Erfahrungen

zfs (RAID0) ?

Ja. Das heißt halt RAID 0 im Installer, ist aber keines mit nur einer Platte. Man kann das später auch bei Bedarf zu einem Mirror (RAID 1) machen.

Was sollte ich nun noch beachten und einstellen / überprüfen ?

Eigenlob stinkt, aber ich würde dir empfehlen meine Tips Liste mal durch zu gehen. ZRAM und meine RAM Reduktions Tips wären zB. eine Idee um den Arbeitsspeicher etwas auszureizen. ARC kann man eventuell auch verringern. Dort wird auch beschrieben wir man vor Füllung des Speichers vorsorgt oder falls es doch voll wird das Problem behebt.

Das Trimmen der VM erfolgt ja nach wie vor über HomeAssistant selber

Solange discard gesetzt ist sollte das für VMs genügen.

 

[TErxleben]

dieses Bild kam bei der Installation.:

Da habe ich jetzt zfs (RAID0) gewählt.
Ich hoffe das war korrekt ?

RAID0 heißt i.d.R zwei Platten, die sich wie eine verhalten. Fällt eine aus, dann sind beide nicht mehr ansprechbar.
RAID1 heißt zwei gespiegelte Platte. Fällt eine aus, arbeitet das System weiter.

Wähle ext4.
Keine Sonderlocken, die dir wegen mangelnder Erfahrung in den den Fuß schießen. Du gewinnst nämlich nichts außer vielleicht Erfahrung die du womöglich nie benötigst.
Also nochmal von vorn und du sammelst die Erfahrung, wie simpel sich ein PVE aufsetzen lässt. Ganze ohne weiter rumschrauben zu müssen.

 

[lethuer]

Dein PVE war wohl zu alt für die Mount Option.

jap beim neuen system gibt es die "discard" option jetzt auch im Container, habe ich also gewählt.

Deins ist spezifisch für bestimmte CT. Meines musst du nie wieder anfassen.

verstehe.

TLDR ist das für CTs (welches auch automatisiert werden sollte)
pct list | awk '/^[0-9]/ {print $1}' | while read ct; do echo "Trimming ${ct}"; pct fstrim ${ct}; done
Und das für VMs
qm list | grep "running" | awk '/[0-9]/ {print $1}' | while read vm; do echo "Trimming ${vm}"; qm guest exec ${vm} -- fstrim -av | jq -r '."out-data"'; doneDas hat aber ein paar Vorraussetzungen wie konfiguriertes discard und den Guest Agent. Ansonsten halt fstrim -av als root innerhalb der VM (braucht auch discard).

ich hab jetzt versucht deine Snippets mal auszuführen:

root@pve:~# pct list | awk '/^[0-9]/ {print $1}' | while read ct; do echo "Trimming ${ct}";  pct fstrim ${ct}; done
Trimming 100
fstrim: /var/lib/lxc/100/rootfs/: the discard operation is not supported

root@pve:~# qm list | grep "running" | awk '/[0-9]/ {print $1}' | while read vm; do echo "Trimming ${vm}"; qm guest exec ${vm} -- fstrim -av | jq -r '."out-data"'; done
Trimming 139
-bash: jq: command not found
No QEMU guest agent configured

Noch scheint das nicht zu laufen und wie würde ich das dann automatisieren ?

Solange discard gesetzt ist sollte das für VMs genügen.

ist gesetzt

 

[Impact]

Die Mount Option ist nicht meine Präferenz. Kann eventuell Performance oder andere Probleme haben. Siehe den Arch Wiki Link dazu. Ich würde pct fstrim ... via crontab -e automatisieren. Bei ZFS CTs ist das aber nicht notwendig. Ist ja aber auch dort beschrieben. Wenn du nur ZFS nutzt kannst du das also weg lassen oder die Meldung ignorieren.
Für das Fehlende jq probier mal apt install jq. Ich war der Meinung das ist vorinstalliert. Habe den Artikel angepasst. Für das andere muss wie erwähnt der Guest Agent konfiguriert und installiert sein: https://pve.proxmox.com/wiki/Qemu-guest-agent
Der sollte generell für jede VM eingerichtet werden.

 

[TErxleben]

Was @Impact referiert, zeigt deutlich den Mehraufwand und lauernde Fallen, den man treiben und im Auge behalten muss.
Nimm ext4 und du hast ganz ohne weitere Rumschrauberei ein System ootb. Vor allem gewinnst du exakt 0,0 mit zfs. Ähnlich wie mit einem Fuchsschwanz an der Manta-Antenne. Wenn du irgendwann Features vermisst die zfs bietet, dann setzt du eben PVE neu auf und probierst es.

 

[Impact]

Das gleiche muss man auch für LVM-Thin tun was der Standard für die ext4 Auswahl ist. Sprich das gilt für fast alle Installationen. Für LVM natürlich nicht da thick. Zu purem LVM zu konvertieren braucht mindestens genau so viel Aufwand wie einen Crontab anzulegen...
Man gewinnt mit ZFS Snapshots, Kompression (meist 2x mehr effektiver Speicher), einfacheres/flexibleres Management und anderes: https://forum.proxmox.com/threads/performance-comparison-between-zfs-and-lvm.124295/#post-541384

 

[TErxleben]

Der ganze fstrim-Voodoo bringt genau soviel wie sauerstofffreie Lautsprecherkabel.
Auch bei Verwendung von LVM-Thin ohne Überprovisionierung bringt es gar nichts, außer SSDs/NMEs mit Schreiblast zu beanspruchen.
Das einzige, was Platz spart, ist regelmäßiges Nullen gelöschter Blöcke innerhalb von VMs. Damit werden sie in Sicherungen weggekürzt und tauchen auch nicht bei Wiederherstellung auf.

 

[lethuer]

Die Mount Option ist nicht meine Präferenz. Kann eventuell Performance oder andere Probleme haben.

gut hatte ich dann wohl falsch verstanden, habe ich wieder raus genommen.

Für das Fehlende jq probier mal apt install jq. Ich war der Meinung das ist vorinstalliert.

hab ich nachinstalliert

Für das andere muss wie erwähnt der Guest Agent konfiguriert und installiert sein: https://pve.proxmox.com/wiki/Qemu-guest-agent
Der sollte generell für jede VM eingerichtet werden.

und den Guest Agent auch aktiviert, jetzt klappts:

root@pve:~# qm list | grep "running" | awk '/[0-9]/ {print $1}' | while read vm; do echo "Trimming ${vm}"; qm guest exec ${vm} -- fstrim -av | jq -r '."out-data"'; done
Trimming 139
/tmp: 14.9 MiB (15638528 bytes) trimmed on /dev/zram2
/mnt/data: 47.3 GiB (50766323712 bytes) trimmed on /dev/sda8
/mnt/overlay: 83.9 MiB (87956480 bytes) trimmed on /dev/sda7
/mnt/boot: 31.2 MiB (32710656 bytes) trimmed on /dev/sda1

Ich würde pct fstrim ... via crontab -e automatisieren

hab es dann hier jetzt auch in nano /etc/crontab wieder raus genommen:


bedeutet dann so wäre in crontab -e korrekt ?



hieße die fstrim Automation in HomeAssistant würde ich dann jetzt auch nicht mehr benötigen und kann ich deaktivieren ?



Wo hattest du hier zum speicher was geschrieben und was ist ARC ?

Eigenlob stinkt, aber ich würde dir empfehlen meine Tips Liste mal durch zu gehen. ZRAM und meine RAM Reduktions Tips wären zB. eine Idee um den Arbeitsspeicher etwas auszureizen. ARC kann man eventuell auch verringern.

Ich hab das neue system jetzt mit ZFS aufgesetzt. aber das war jetzt eine 50/50 entscheidung ohne das wirklich bewerten zu können
ich danke euch beiden in jedem falle für den Support ! @Impact & @TErxleben

Ja. Das heißt halt RAID 0 im Installer, ist aber keines mit nur einer Platte.

Wähle ext4.
Keine Sonderlocken, die dir wegen mangelnder Erfahrung in den den Fuß schießen.

Ich würde pct fstrim ... via crontab -e automatisieren. Bei ZFS CTs ist das aber nicht notwendig. Ist ja aber auch dort beschrieben. Wenn du nur ZFS nutzt kannst du das also weg lassen oder die Meldung ignorieren.

Nur um jetzt sicherzugehen... Bei ZFS (RAID0) benötige ich kein trimmen und bei LVM (ext4) würde ich das schon benötigen ?

 

[TErxleben]

ch hab das neue system jetzt mit ZFS aufgesetzt. aber das war jetzt eine 50/50 entscheidung
ich danke euch beiden in jedem falle für den Support ! @Impact & @TErxleben

Mit ordentlicher Datensicherung kannst du ja komfortabel wechseln.

 

[Impact]

bedeutet dann so wäre in crontab -e korrekt ?

Für CTs ja, für VMs ist es nicht notwendig. Die machen das ja selbst. Normalerweise wöchentlich. Hier ist das Snippet nur zum testen bzw. bei Bedarf um es sofort auszulösen.

hieße die fstrim Automation in HomeAssistant würde ich dann jetzt auch nicht mehr benötigen und kann ich deaktivieren ?

Ja. HAOS macht das selbst. Ich glaube das hätte via HA Automation eh nicht funktioniert. Das muss auf Systemebene ausgeführt werden, nicht innerhalb eines Docker Containers wie HA Automationen es tun.

Nur um jetzt sicherzugehen... Bei ZFS (RAID0) benötige ich kein trimmen und bei LVM (ext4) würde ich das schon benötigen ?

Kommt darauf an von wo man spricht. Im Kontext von Gästen brauchst du discard/fstrim immer dann wenn der Speicher Thin Provisioniert ist. Bei ZFS ist er das. Bei LVM-Thin, was wie gesagt Standard ist, auch.

Der ganze fstrim-Voodoo bringt genau soviel wie sauerstofffreie Lautsprecherkabel.

Sorry aber du machst dich lächerlich.

 

[lethuer]

Ja. HAOS macht das selbst. Ich glaube das hätte via HA Automation eh nicht funktioniert. Das muss auf Systemebene ausgeführt werden, nicht innerhalb eines Docker Containers wie HA Automationen es tun.

doch das funktioniert, siehe hier: https://forum.proxmox.com/threads/local-lvm-wird-voll.145372/post-655346
und anscheinend macht HA das eben wohl doch nicht immer. sonst wäre mir damals der speicher wohl nicht voll gelaufen.

 

[TErxleben]

Für CTs ja, für VMs ist es nicht notwendig. Die machen das ja selbst. Normalerweise wöchentlich. Hier ist das Snippet nur zum testen bzw. bei Bedarf um es sofort auszulösen.


Ja. HAOS macht das selbst. Ich glaube das hätte via HA Automation eh nicht funktioniert. Das muss auf Systemebene ausgeführt werden, nicht innerhalb eines Docker Containers wie HA Automationen es tun.


Kommt darauf an von wo man spricht. Im Kontext von Gästen brauchst du discard/fstrim immer dann wenn der Speicher Thin Provisioniert ist. Bei ZFS ist er das. Bei LVM-Thin, was wie gesagt Standard ist, auch.


Sorry aber du machst dich lächerlich.

Während du deinen persönlichen zfs-Fetisch in völlig unangebrachten Szenarien propagierst?
Warum verwendet Proxmox diese achso weit überlegene zfs-Technik nicht per default? Sind die doof?
Oder arbeiten die womöglich nach dem KISS-Prinzip?

Es geht hier immer noch um ein Problem, welches durch definitiv zu klein verwendete HW verursacht wurde. Den Rest kann sich @lethuer sicher aus den inzwischen sieben Seiten raussuchen.

 

[Impact]

Warum verwendet Proxmox diese achso weit überlegene zfs-Technik nicht per default?

Relevant: https://bugzilla.proxmox.com/show_bug.cgi?id=7614

 

[TErxleben]

Relevant: https://bugzilla.proxmox.com/show_bug.cgi?id=7614

Sag ich doch die ganze Zeit und zitiere:

It might be time again to reevaluate the per-default selected storage/filesystem to be used for the root filesystem.
We currently use LVM-Thin with ext4, which is certainly still not a bad choice, it's not as featurefull and flexible compared to ZFS, and might also have some slight performance drawbacks.

This will not matter for more experienced users, but can make a lot of difference for those starting out or just evaluating PVE (and other Proxmox projects) the first time.

Personally I'd always prefer a mainlined FS, but there really is none that has the same full featureset, maturity, and tooling stability and polishing as ZFS has. btrfs, for example, hasn't even an actual event daemon nor polishing like just booting when a single part of a fully redundant mirror failed. LVM/LVM-Thin has no reliable redundancy and misses some other features too. bcachefs sounded like it might become a good option, but it's currently not in mainline, so no real justification to switching from ZFS to it at all at the moment for us (were ZFS is battle proven).

We nowadays also have more sensible default for some ZFS pitfalls like ARC limits, so the drawbacks here are becomming smaller (non-existent?).

This isn't something to just decide on a whim, so just recording it here for now.

Du unterstreichst recht eindrücklich, warum zfs eben NICHT als Standard für Anfänger festgelegt ist.

 

[Impact]

Vielleicht liest du das Zitat noch mal. Der Author macht in meinen Augen ein Argument für ZFS, nicht dagegen.

 

[TErxleben]

Vielleicht liest du das Zitat noch mal. Der Author macht in meinen Augen ein Argument für ZFS, nicht dagegen.

Was habe ich denn überlesen um ein Argument für zfs herauszulesen?

We nowadays also have more sensible default for some ZFS pitfalls like ARC limits, so the drawbacks here are becomming smaller (non-existent?).

This isn't something to just decide on a whim, so just recording it here for now.

Genau darum empfehle ich Anfängern den von Proxmox gesetzten Default zu nutzen, statt den Laden ohne Hintergrundwissen überflüssigerweise zu pimpen.

 

[ThoSo]

So neues Proxmox ist drauf mit zfs (RAID0) und unter Datecenter->pve->Updates alles installiert.
Das hat jetzt inkl. Wiederherstellung der Backups tatsächlich nur 2h gedauert und ich sollte wieder ein vernünftiges System haben...

Dann hast es erst einmal soweit überstanden - Prima!
Ich drücke die Daumen das es auch die nächste Zeit stabil läuft.
Schönes Wochenende

 

[lethuer]

Ich hab noch diesen Hinweis auf dem Bildschirm (nicht aber auf der Konsole) finden können:

kvm_intel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3846 and https://kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.

https://www.thomas-krenn.com/de/wiki/L1TF

Was tun ? Sollte ich das BIOS updaten ?