Nach Update auf Proxmox 8.1

[flomojoe]

Hallo zusammen,
nach dem Update auf Proxmox 8.1 hängen sich regelmäßig Debian und Ubuntu VM´s auf, so dass div. Dienste nicht mehr erreichbar sind.
In den Consolen der VM`s findet man unzählige Meldungen:

[180402.884809] INFO: task journal-offline: 150735 blocked for more than 362 seconds.
[180402.884877] Not tainted 5.15.0-89-generic #99-Ubuntu
[180402.884917] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1180402.885016] INFO: task nmbd:674 blocked for more than 120 seconds.
[180402.885037]Not tainted 5.15.0-89-generic #99-Ubuntu
[180402.885054]"echo 0 > /proc/sys/kernel/hung-task_timeout_-secs" disables this message.
[180402.885216] INFO: task kworker/u16:1:150314 blocked for more than 362 seconds.
[180402.885239]Not tainted 5.15.0-89-generic #99-Ubuntu
[180402.885257]"'echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[181114.141023] systemd[1]: Failed to start Journal Service.
[181565.389650] systemd[1]: Failed to start Journal Service.
[182016.637269] systemd[1]: Failed to start Journal Service.
[182467.887308] systemd[1]: Failed to start Journal Service.


Es schafft dann nur noch ein "Hard reset" der VM Abhilfe.
Mit 8.0 und 7.X funktioniert alles reibungslos. Die Rechereche hat ergeben, dass es an Performance-Problemen liegen kann. Es sind 3 Supermicro Server als Cluster konfiguriert mit einem Ceph Storage pro Server eine NVME SSD, die Server sind mit 100 Gigabit mit Melanox Adapter verbunden. Rados mißt knapp r/w 1800 MB/s auf jedem Node.

Hat jemand eine Idee bzw. einen Ansatz?

Vielen Dank und schöne Grüße

flomojoe

 

[Falk R.]

Eventuell liegt es ja am LAN und nicht am Storage. Wie sieht denn die restliche Konfiguration aus?

 

[flomojoe]

Die Nodes hängen jeweils mit 4x10G LACP auf 2 MikroTik Switche mit 40G Uplink. Die Nodes sind identisch ausgestattet: Xeon 72 Kerne auf 2 Sockets und jeweils 320GB RAM. Aktuell laufen nur 13 VM´s. und auf Node 3 läuft ein PBS.
Diese Probleme gibt es seit 8.1 nur bei Debian und Ubuntu, Windows und macOS läuft problemlos.

 

[Falk R.]

Das ist schon etwas komisch. Wie sehen denn die VM Konfigurationen aus, gibt es zwischen einer Linux VM und einer Windows unterschiedliche Einstellungen?

Was mich persönlich interessiert, wie machst du denn ein LACP über 2 MikroTik Switches?

 

[flomojoe]

Die VM Konfigurationen haben sie nicht verändert, hier Beispiele

WIN:



LINUX:



Bzgl. Switche: Node 1 und 2 gehen mit LACP auf Switch 1, Node 3 mit LACP auf Swicht 2, Switch 1 ist via LAG mit Switch 2 verbunden.

 

[Falk R.]

Die VM Konfigurationen haben sie nicht verändert, hier Beispiele

Kannst du bei den VMs mal den CPU Typ Host probieren?
Ich glaube zwar nicht, dass deswegen die Kisten abschmieren, aber die sollten auf jeden Fall schneller laufen.

Bzgl. Switche: Node 1 und 2 gehen mit LACP auf Switch 1, Node 3 mit LACP auf Swicht 2, Switch 1 ist via LAG mit Switch 2 verbunden.

OK, das ist zwar nicht Redundant aber läuft.
Ich baue lieber zwischen den Switches ein MLAG und da das eine statische LAG ist, nutze ich dann Balance-RR. Damit könntest du eine LAG über beide Switches verteilen um eine echte Redundanz zu bekommen.

 

[flomojoe]

Ok habe 2 VMs umgestellt, mal abwarten was passiert.

Bin gerne noch für alternative Ansätze zu haben.

 

[Neobin]

Welche PVE-Kernel Version läuft aktuell auf dem Host (pveversion -v)?
Taucht in den VMs etwas wie: rcu_sched self-detected stall on CPU auf?

Siehe:
https://forum.proxmox.com/threads/failed-to-start-journal-service.137524/post-612409

 

[flomojoe]

proxmox-ve: 8.1.0 (running kernel: 6.5.11-6-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5: 6.5.11-6
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
proxmox-kernel-6.2.16-19-pve: 6.2.16-19
proxmox-kernel-6.2: 6.2.16-19
proxmox-kernel-6.2.16-15-pve: 6.2.16-15
proxmox-kernel-6.2.16-8-pve: 6.2.16-8
proxmox-kernel-6.2.16-6-pve: 6.2.16-7
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph: 17.2.7-pve1
ceph-fuse: 17.2.7-pve1
corosync: 3.1.7-pve3
...

"rcu_sched self-detected stall on CPU" taucht in den VM´s nicht auf.

Es ist aber eine Intel Xeon Gold 6150 CPU ...

 

[fiona]

Hi,
werden bei den VMs Backups/Snapshots gemacht? Hilft ein qm suspend <ID> && qm resume <ID> (echte ID der VM statt <ID> benutzen) nachdem es hängt? Ohne --todisk ist ein qm suspend <ID> das selbe wie pausieren in der UI.

 

[flomojoe]

Hallo fiona, ich habe das geprüft, es laufen alle 2 Std. Snapshots der VMs. Man kann die Laufzeit der VMs mit dem Befehl verlängern. Trotzdem laufen sie dann mit der Zeit in die bekannten Fehler, dass relevante Dienste nicht mehr erreichbar sind.

 

[flomojoe]

Leider besteht das Problem weiterhin, was gibt es noch für Möglichkeiten?

 

[Falk R.]

Wie sehen denn die Einstellungen im BIOS aus?
C-States mal abschalten. Bei Ceph empfehle ich das eh immer.
Eventuell mal testweise P-States (Turbo Mode) deaktivieren.

 

[fiona]

Ist das Problem je bei einer VM mit IDE/SATA Disken oder ohne iothread aufgetreten? Falls nein, könntest Du als Workaround derweil iothread abschalten. Und dann könnte dieser Patch Abhilfe schaffen. Muss erst noch reviewed und intern noch etwas länger getestet werden, aber wenn alles gut geht wird er vermutlich in Version pve-qemu-kvm >= 8.1.2-5 drinnen sein.

 

[flomojoe]

Die VM sind alle mit SCSI und iothread=1 eingerichtet. Schalte ich das Backup (Snapshots) alle 2 Std. aus, so ist der Fehler weg.
So werde ich wohl mit weniger Snapshots leben müssen und auf das Update warten und hoffen, dass es dann wieder läuft.

Danke an alle! Ich melde mich, wenn es mit dem Patch wiedererwartend nicht funktioniert.

 

[Neobin]

Der obengenannte Patch musste (vorerst) zurückgezogen werden:
https://forum.proxmox.com/threads/vms-hung-after-backup.137286/post-616234

 

[Falk R.]

Also ist der 8.1.2-6 gleich zum 8.1.2-4?

 

[Neobin]

Also ist der 8.1.2-6 gleich zum 8.1.2-4?

Nein, 8.1.2-5 enthält auch noch:
https://git.proxmox.com/?p=pve-qemu.git;a=commit;h=dfac4f359304a80a34ead27d31090a67c36fb7ee

[0] https://git.proxmox.com/?p=pve-qemu.git;a=commitdiff;h=c6eb05a79954fd490e2e09708c86aafb89554043

 

[Falk R.]

Aber der 8.1.2-5 ist ja die Version welche die CPU Auslastung nach den Backups erzeugt.
Deshalb die Frage.

 

[Neobin]

Ich würde sagen, aufgrund dieses Problems:
https://forum.proxmox.com/threads/pve-100-cpu-on-all-kvm-while-vms-are-idle-at-0-5-cpu.138140
will man generell zur Zeit entweder auf: 8.1.2-4 oder: 8.1.2-6 sein, ja.

Sollte man von diesem Problem:
https://forum.proxmox.com/threads/vms-hung-after-backup.137286
betroffen sein, so wie vermutlich auch dieser Thread hier, gibt es noch (bzw. wieder) keinen Fix und man muss/müsste den Workaround mit dem Deaktivieren von: iothread für alle vDisks bei allen (betroffenen?) VMs benutzen.