Zeitsprünge in VMs seit PVE 7.2

A

Andreas Pflug

Active Member
Nov 13, 2019
32
2
28
Seit mein Cluster auf 7.2 ist, passiert es ab und zu daß in VMs Zeitsprünge auftreten, stets in Zusammenhang mit Migrationen aufgetreten (nicht unbedingt der betroffenen Maschine selber). Beim jüngsten Fall ist der Zeitsprung passiert, während eine andere VM neu gestartet wurde, daher denke ich daß der VM-auf-Zielhost-starten Teil der Migration jeweils der auslöser war.

Während eine frische Debian-VM startete, zeigte eine Windows10 VM (pc-i440fx-6.0) im Systemlog:
  • 26.07. - 08:52:02: Letzte richtige Uhrzeit
  • 02.08. - 03:52:44: Erste falsche Zeit (eventId 6013) "Die aktive Systemzeit ist 2237317 Sekunden."
  • 02.08. - 03:57:46: Letzte falsche Uhrzeit
  • 26.07. - 08:59:38: Erste richtige Uhrzeit
Das Kernel Log des PVE-Hosts zeigt keine Informationen. Host ist ein Epyc ZEN-3 Server, MT enabled.
 
Hi,
haben Source- und Target-Knoten die selbe CPU?

Was ist die Ausgabe von pveversion -v am Source- und am Target-Knoten?

Wurden die Maschinen in der Zwischenzeit neu gestartet? Ansonsten wäre auch die Ausgabe von
Code: 
qm status <ID> --verbose | grep qemu
jeweils für die Debian VM und Windows 10 VM interessant.

EDIT: Am besten auch die Konfiguration der VMs mit qm config <ID> posten.

Ganz dumme Frage, nur um sicher zu gehen: Mit der "frischen" Debian-VM ist die Instanz, die migriert wurde, gemeint?
 
Last edited:
Das obige Ereignis ist NICHT das Ergebnis einer Migration, sondern eine (vormals auf einer anderen Maschine geclonten und kalt migrierten) gestoppte VM wurde gestartet (qm start über GUI).

Der Update auf 7.2 erfolgte im Mai, mit folgenden Versionen:
proxmox-ve: 7.2-1 (running kernel: 5.15.30-2-pve) pve-manager: 7.2-3 (running version: 7.2-3/c743d6c1) pve-kernel-helper: 7.2-2 pve-kernel-5.15: 7.2-1 pve-kernel-5.15.30-2-pve: 5.15.30-3 ceph: 15.2.16-pve1 ceph-fuse: 15.2.16-pve1 corosync: 3.1.5-pve2 criu: 3.15-1+pve-1 glusterfs-client: 9.2-1 ifupdown: 0.8.36+pve1 libjs-extjs: 7.0.0-1 libknet1: 1.22-pve2 libproxmox-acme-perl: 1.4.2 libproxmox-backup-qemu0: 1.2.0-1 libpve-access-control: 7.1-8 libpve-apiclient-perl: 3.2-1 libpve-common-perl: 7.1-6 libpve-guest-common-perl: 4.1-2 libpve-http-server-perl: 4.1-1 libpve-storage-perl: 7.2-2 libspice-server1: 0.14.3-2.1 lvm2: 2.03.11-2.1 lxc-pve: 4.0.12-1 lxcfs: 4.0.12-pve1 novnc-pve: 1.3.0-3 proxmox-backup-client: 2.1.8-1 proxmox-backup-file-restore: 2.1.8-1 proxmox-mini-journalreader: 1.3-1 proxmox-widget-toolkit: 3.4-10 pve-cluster: 7.2-1 pve-container: 4.2-1 pve-docs: 7.2-2 pve-edk2-firmware: 3.20210831-2 pve-firewall: 4.2-5 pve-firmware: 3.4-1 pve-ha-manager: 3.3-4 pve-i18n: 2.7-1 pve-qemu-kvm: 6.2.0-5 pve-xtermjs: 4.16.0-1 qemu-server: 7.2-2 smartmontools: 7.2-pve3 spiceterm: 3.2-2 swtpm: 0.7.1~bpo11+1 vncterm: 1.7-1 zfsutils-linux: 2.1.4-pve1

qm status liefert running-qemu: 6.2.0 Die Debian-Maschine war nicht mehr ansprechbar, zeigte auf der Console folgendes an:

[11293296.368374] rcu: INFO: rcu_sched self-detected stall on CPU [11293296.368397] rcu: #3-...!: (1 ticks this GP) idle=732/0/0x01 softirq=2016033/2016033 fqs=1 [13405352.547830] rcu: INFO: rsu_sched self-detected stall on CPU [13405352.547860] rcu: #2-...!: (1 GPs behind) idle=e22/0/0x01 softirq=222692/222693 fqs=1 [13405352.547882] rcu:: rcu_sched kthread starved for 527765585 jiffies g6500433 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1 [13405352.547905] rcu: #Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behaviour.

Die Debian-Maschine wurde rebootet, die Windows10-VM läuft seitdem (ohne Reboot) normal. AFAICS wurden beide Maschinen im Mai auf dem betroffenen Proxmox-Host gestartet, nicht migriert.

Für mich fühlt sich das so an, als ob eine VM mit dem CPU-Zustand einer anderen VM (was den Timer betrifft) weiterarbeitet. Was natürlich eigentlich nie nicht passieren kann/darf.

Die leicht redigierten Konfigurationen:
description: Windows 10 agent: 1 boot: order=virtio0 cores: 4 cpu: EPYC machine: pc-i440fx-6.0 memory: 8192 name: w10 net0: virtio=fe:01:c0:11:11:11,bridge=vmbr0,firewall=1,tag=175 numa: 0 ostype: win10 protection: 1 scsihw: virtio-scsi-pci smbios1: uuid=a... sockets: 1 virtio0: drbd-ssd:vm-114-disk-1,discard=on,size=40G vmgenid: 9999... description: Debian 11 agent: 1 boot: order=virtio0;net0 cores: 4 cpu: EPYC memory: 4096 name: d11 net0: virtio=fe:01:c0:22:22:22,bridge=vmbr0,tag=177 numa: 0 ostype: l26 protection: 1 scsihw: virtio-scsi-pci smbios1: uuid=2a... sockets: 1 virtio0: drbd-ssd:vm-215-disk-1,size=8G vmgenid: eccc...
 
Leider noch nicht. Ich hatte mal einen ähnliche Situation, als ich einen Snapshot von einer VM einer fremden Maschine geladen habe, wo dann andere laufende VMs plötzlich einen Zeitsprung hatten. Ich dachte das wäre nur, weil der Snapshot von einer Maschine mit cpu=host und von einer Intel-CPU kam (meine Workstation hat eine AMD-CPU). Migration bzw. Snapshot laden wenn CPU-Vendor anders ist, ist reine Glückssache. Möglicherweise ist da allerdings mehr dran, und ich werde mir das bei Gelegenheit nochmal anschauen. Im Moment versuche ich allerdings ein anderes Problem nachzustellen, wo die Gäste für lange Zeit in Betrieb bleiben müssen, also möchte ich da jetzt nicht dazwischenfunken.

Ist bei Dir das Problem erneut aufgetreten? Wenn ja, nach welchen Aktionen?
 
Bisher nicht wieder aufgetreten, allerdings vermeiden wir VM-Starts zZt weitestgehend weil das fatale Auswirkungen haben kann (Dokumente in der Zukunft). Bei den 3 VM-Starts "unter Aufsicht" seitdem noch nicht wieder aufgetreten.
Der Cluster ist rein Epyc (Zen1/2/3). Allerdings trat das Problem ja auch mit VMs auf die niemals live migriert worden waren.
Ich hatte schon mal kurz beim qemu-Projekt reingesehen ob seit qemu 6.2 irgendwas spannendes anders ist, hab aber nichts sehen können.
Der von dir geschilderte Fall riecht für mich genauso; eine VM (egal wie kaputt) darf ja niemals andere VMs beeinflussen.
 
Last edited:
Gerade wieder passiert. Start einer Windows-VM, Einschlag in einer anderen Windows-VM. Laut Task Log wurden in den letzten 10 Tagen nur 1 weiteres Mal eine VM gestartet, seinerzeit ohne Problem Demnach ist die Fehlerrate 50%...
 
Last edited:
Nächste Woche hab ich eine Maschine frei um das für uns zu testen. Ich hoffe ich kann den Bug auf Ryzen halbwegs häufig reproduzieren.
 
Hallo zusammen,

seit der Umstellung auf DL380 G9s letzte Woche haben wir nun auch Probleme mit dem gesamten Cluster. Die P440ar Karte ist im HBA Modus.

Die Maschinen geben genau das Problem wie hier beschrieben wieder. Windows ist noch katastrophaler, und lässt sich nichtmal wirklich installieren oder nutzen.

Ich habe folgende Ansetze bereits probiert:
- Umstellung von ZFS auf btrfs RAID
- Anstatt virtio-scsi oder virtio-block, SATA oder IDE nutzen
- GPU von Windows VM entfernen
- Kernel aus dem Post nutzen (https://forum.proxmox.com/threads/p...on-linux-freeze-on-windows.109645/post-488479)
- Kernel 5.13 getestet

Die Probleme treten jedoch weiterhin auf.
 
Hi,
d3dx9 said:
Hallo zusammen,

seit der Umstellung auf DL380 G9s letzte Woche haben wir nun auch Probleme mit dem gesamten Cluster. Die P440ar Karte ist im HBA Modus.
Click to expand...
welches CPU-Modell hast Du genau?

d3dx9 said:
Die Maschinen geben genau das Problem wie hier beschrieben wieder. Windows ist noch katastrophaler, und lässt sich nichtmal wirklich installieren oder nutzen.
Click to expand...
Zeitsprünge? RCU stalls? Treten die Probleme beim Starten/Migrieren einer (anderen?) VM auf?

d3dx9 said:
Ich habe folgende Ansetze bereits probiert:
- Umstellung von ZFS auf btrfs RAID
- Anstatt virtio-scsi oder virtio-block, SATA oder IDE nutzen
- GPU von Windows VM entfernen
- Kernel aus dem Post nutzen (https://forum.proxmox.com/threads/p...on-linux-freeze-on-windows.109645/post-488479)
- Kernel 5.13 getestet

Die Probleme treten jedoch weiterhin auf.
Click to expand...
Wenn es mit Kernel 5.13 auftritt, ist es nicht dasselbe Problem wie bei mir. Gibt es irgendwelche Meldungen in /var/log/syslog? Bitte auch die Ausgabe von pveversion -v posten.
 
Hi Fiona,

es handelt sich hierbei um Xeon E5-2690v3 mit 512GB DDR4 ECC RAM direkt von HPE. Ich habe auch auf die aktuellere BIOS Version geupdated, diese bringt auch keinen Unterschied.

Bei Windows kann ich leider keine Logs einsehen, ich wüsste zumindest nicht wie. Aber unter Linux sehe
1662111429906.png

Die VMs sind dann auch unresponsive. Das Problem tritt jedoch bei allen 3 Hosts im Cluster auf, diese sind komplett Identisch.

Der Host, der die Windows VM drauf hat ist:
Code: 
root@hv02:~# pveversion
pve-manager/7.2-7/d0dd0e85 (running kernel: 5.13.19-6-pve)
root@hv02:~# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.13.19-6-pve)
pve-manager: 7.2-7 (running version: 7.2-7/d0dd0e85)
pve-kernel-5.15: 7.2-9
pve-kernel-helper: 7.2-9
pve-kernel-5.15.39-4-pve: 5.15.39-4
pve-kernel-5.15.39-3-pve-guest-fpu: 5.15.39-3
pve-kernel-5.15.30-2-pve: 5.15.30-3
pve-kernel-5.13.19-6-pve: 5.13.19-15
ceph-fuse: 15.2.16-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve1
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-2
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-3
libpve-storage-perl: 7.2-8
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.5-1
proxmox-backup-file-restore: 2.2.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-2
pve-container: 4.2-2
pve-docs: 7.2-2
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-5
pve-firmware: 3.5-1
pve-ha-manager: 3.4.0
pve-i18n: 2.7-2
pve-qemu-kvm: 7.0.0-2
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1

Der Host wo ich die RCU Probleme sehen konnte:

Code: 
root@hv01:~# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.39-3-pve-guest-fpu)
pve-manager: 7.2-7 (running version: 7.2-7/d0dd0e85)
pve-kernel-5.15: 7.2-9
pve-kernel-helper: 7.2-9
pve-kernel-5.15.39-4-pve: 5.15.39-4
pve-kernel-5.15.39-3-pve-guest-fpu: 5.15.39-3
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph-fuse: 15.2.16-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve1
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-2
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-3
libpve-storage-perl: 7.2-8
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.5-1
proxmox-backup-file-restore: 2.2.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-2
pve-container: 4.2-2
pve-docs: 7.2-2
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-5
pve-firmware: 3.5-1
pve-ha-manager: 3.4.0
pve-i18n: 2.7-2
pve-qemu-kvm: 7.0.0-2
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.5-pve1

Im syslog stehen keinerlei Probleme, ich kann jedoch auch nicht erkennen, dass irgendwie hoher IO Load in den Momenten besteht.

Gruß und danke,
d3dx9
 

Attachments

  • 1662111420430.png
    1662111420430.png
    41 KB · Views: 8
Mittlerweile gibt es ein Kernel-Paket für 5.19 auf allen Repositories, das mit apt install pve-kernel-5.19 installiert werden kann. Damit sollten die Zeitsprünge/CPU stalls mit AMD-Prozessoren behoben sein. Beim Problem von @d3dx9 wäre ich mir weniger sicher, aber einen Versuch sollte es trotzdem wert sein.
 
Hallo Zusammen,

wir sind neu bei Proxmox und bauen gerade unser 5 Node Cluster Stück für Stück auf, sind auch von diesem Problem betroffen.
Unsere Lösung fürs Erste ist, die Server herunterzufahren und dann die nötigen Migrationen offline ausführen.


Zum Fix im Kernel-Paket 5.19 stellt sich mir die Frage, warum unsere Proxmox-Server zum heutigen Stand mehrere Kernelversionen zurückliegen.
Ist ein manuelles Kernel-Update für Produktiv-Systeme ratsam, gibt es seitens Proxmox-Team eine Empfehlung?

Mit freundlichen Grüßen


Code: 
proxmox-ve: 7.2-1 (running kernel: 5.15.60-2-pve)
pve-manager: 7.2-11 (running version: 7.2-11/b76d3178)
pve-kernel-helper: 7.2-13
pve-kernel-5.15: 7.2-12
pve-kernel-5.15.60-2-pve: 5.15.60-2
pve-kernel-5.15.60-1-pve: 5.15.60-1
pve-kernel-5.15.53-1-pve: 5.15.53-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph-fuse: 15.2.16-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve1
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-3
libpve-guest-common-perl: 4.1-3
libpve-http-server-perl: 4.1-4
libpve-storage-perl: 7.2-10
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.7-1
proxmox-backup-file-restore: 2.2.7-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-2
pve-container: 4.2-2
pve-docs: 7.2-2
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-6
pve-firmware: 3.5-4
pve-ha-manager: 3.4.0
pve-i18n: 2.7-2
pve-qemu-kvm: 7.0.0-3
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.6-pve1
 
Hi,
Schneckdeploy said:
Hallo Zusammen,

wir sind neu bei Proxmox und bauen gerade unser 5 Node Cluster Stück für Stück auf, sind auch von diesem Problem betroffen.
Unsere Lösung fürs Erste ist, die Server herunterzufahren und dann die nötigen Migrationen offline ausführen.


Zum Fix im Kernel-Paket 5.19 stellt sich mir die Frage, warum unsere Proxmox-Server zum heutigen Stand mehrere Kernelversionen zurückliegen.
Ist ein manuelles Kernel-Update für Produktiv-Systeme ratsam, gibt es seitens Proxmox-Team eine Empfehlung?
Click to expand...
der 5.19-er Kernel ist momentan nur Opt-In, hier steht wie man ihn installieren kann.

Es gibt einen Vorschlag, um den Fix zu backporten, aber wurde noch nicht eingepflegt. Wahrscheinlich war die Hoffnung, dass das Kernel-Team von Ubuntu das macht und wir es nicht selbst machen müssen. Ist allerdings noch nicht passiert, also werde ich den Patch mal pingen.
 
@fiona Es scheint immer noch kein pve-kernel verfügbar zu sein den ich verwenden könnte? Um mein zweites Problem zu fixen benötige ich 5.15.75,+ 5.19.17 oder 6.0.3+, wobei mir unklar ist, in wie weit 5.15 das KVM clock Problem löst.

Könnte ich alternativ linux-image-6.0.0 aus bullseye-backports (das ist 6.0.3) verwenden, bzw. an welchen Ecken könnte ich Probleme bekommen?
 
Andreas Pflug said:
@fiona Es scheint immer noch kein pve-kernel verfügbar zu sein den ich verwenden könnte? Um mein zweites Problem zu fixen benötige ich 5.15.75,+ 5.19.17 oder 6.0.3+, wobei mir unklar ist, in wie weit 5.15 das KVM clock Problem löst.

Könnte ich alternativ linux-image-6.0.0 aus bullseye-backports (das ist 6.0.3) verwenden, bzw. an welchen Ecken könnte ich Probleme bekommen?
Click to expand...
Sorry, habe die Erwähnung im anderen Thread wohl übersehen oder keine Notification bekommen :/ Der Fix für die Zeitsprünge ist mittlerweile für 5.15 gebackported worden und ist in pve-kernel-5.15.74-1-pve enthalten, aber der von Dir verlinkte Commit noch nicht. In pve-kernel-5.19.17-1-pve scheint der Commit allerdings enthalten zu sein.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom