Windows 2025 Freeze seit PVE 9.2.2

K

Khensu

Member
Proxmox Subscriber
Feb 3, 2023
70
25
23
Hallo Proxmox Forum,

wir haben aktuell eine Situation bei welchem nach einem Update auf Proxmox 9.2.2 (bzw. vermutlich Kernel 7.0 / QEMU 11) eine Windows 2025 VM spontan mit CPU 100% einfriert und nicht mehr reagiert.
Nach einer gewissen Zeit erholt sich diese allerdings und funktioniert wieder normal.
Dies passiert seit dem Update regelmäßig und passiert entweder direkt zum Start der VM oder unerwartet während des laufenden Betriebs.

In den Ereignislogs der VM selbst ist nichts zu sehen.
Im Anhang befindet sich die VM Konfiguration samt einem Auszug von gdb und strace während die VM hängt.
Wir vermuten, dass es mit dem USB Passthrough zusammenhängt, da kurz vor dem Freeze ein USB Reset stattgefunden hat und die split locks kurz darauf auftreten.

Dies passiert auch nur bei dieser VM.
VirtIO Treiber waren erst 285 installiert, jedoch auf 271 gedowngraded.

Wir versuchen mal die QEMU Maschinenversion auf 10 zu reduzieren und beobachten das Verhalten.
Eventuell hat jemand in der Zwischenzeit eine bessere Idee?

Wir sind für jede Hilfe dankbar :)

Mit besten Grüßen
 

Attachments

Hi, teste mal bitte ob das auch auftritt, wenn du das Nested Virtualisierungs Flag auf der CPU entfernst.
 
  • Like
Reactions: ThoSo and _derTim
Die split_lock_detect Meldungen im dmesg sind ziemlich eindeutig der Auslöser für die Freezes. Der Kernel 7.0 fängt Split-Lock-Zugriffe aus der VM ab und bremst die vCPU-Threads aus, das erklärt die 100% CPU und dann gehts wieder normal.

Was @Falk R. sagt auf jeden Fall testen. Würd ich mal den Kernel-Parameter split_lock_detect=off setzen (in /etc/kernel/cmdline, dann proxmox-boot-tool refresh und reboot). Wenn die Freezes damit weg sind, wisst ihr, dass es daran liegt.

Das USB-Gerät (Gemalto Smartcard-Reader?) scheint die Split Locks zu triggern, im dmesg kommen die USB-Resets direkt vor den split_lock traps. Vllt auch mal testweise ohne USB-Passthrough laufen lassen, um das einzugrenzen.
 
Erstmal danke an alle die einen Hinweis gegeben haben.
Wir haben die VM nun umkonfiguriert und seitdem läuft die VM bereits seit mehreren Tagen ohne Freeze.
Folgende Konfiguration, in rot alle Änderungen im Vergleich zu der Originalkonfiguration aus meiner initialen Anfrage.

~# qm config 100
agent: 1
bios: ovmf
boot: order=scsi0;ide2
cores: 16
cpu: x86-64-v3
efidisk0: Pool0:vm-100-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
ide2: none,media=cdrom
machine: pc-q35-10.2
memory: 16384
meta: creation-qemu=10.1.2,ctime=1768994644
name: [red]
net0: virtio=BC:24:11:85:C7:27,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win11
scsi0: Pool0:vm-100-disk-1,discard=on,iothread=1,size=96G,ssd=1
scsi1: Pool0:vm-100-disk-3,discard=on,iothread=1,size=220G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=[red]
sockets: 1
startup: order=4
tpmstate0: Pool0:vm-100-disk-2,size=4M,version=v2.0
usb0: host=072f:b100
vga: virtio,memory=256
vmgenid: [red]

An was es letztendlich gelegen hat können wir nicht sagen. Die alleinige Umstellung des Maschinentyps hat jedenfalls nicht gereicht.
Wir haben ebenfalls die Laufwerke von virtio zu scsi umgestellt und die Treiber sauber auf 271 gedowngraded.

Eine Datenbank in dieser VM hat wohl noch hohe Latenzen / Reaktionszeiten, hier kontaktiert der Kunde allerdings den Softwarelieferanten, da es ggf. nicht mit Proxmox zu tun hat.

Noch eine Anmerkung zum Schluss. Es kommt wohl stark darauf an, was in der VM läuft. Da der Kunde wohl noch eine andere Windows VM besitzt mit identischer Konfiguration wie initial, und diese läuft ohne Probleme. Allerdings läuft dort auch nur ein Veeam drin und keine Datenbanken.
 
  • Like
Reactions: sgw
Schön dass es jetzt läuft. Zur DB-Latenz würd ich aber nicht zu schnell den Softwarelieferanten verantwortlich machen, das könnte noch am selben Thema hängen. Check mal mit dmesg -w ob unter DB-Last weiterhin split_lock traps reinkommen. Durchaus möglich, dass die Datenbank selbst Verursacher der Split Locks ist (unaligned atomics), nicht der USB-Reader. Solange die Detection an ist, bremst der Host bei jedem Trap die vCPU aus, und das macht sich als Latenz bemerkbar, auch wenn die VM nicht mehr komplett einfriert.

Wenn da noch traps kommen: testweise split_lock_detect=off in die Kernel-Cmdline (/etc/kernel/cmdline, dann proxmox-boot-tool refresh + reboot) und schauen obs bei den Reaktionszeiten was bringt. Das würde auch erklären, warum die zweite VM mit nur Veeam sauber läuft, die macht solche Zugriffe halt nicht.
 
Khensu said:
Erstmal danke an alle die einen Hinweis gegeben haben.
Wir haben die VM nun umkonfiguriert und seitdem läuft die VM bereits seit mehreren Tagen ohne Freeze.
Folgende Konfiguration, in rot alle Änderungen im Vergleich zu der Originalkonfiguration aus meiner initialen Anfrage.

~# qm config 100
agent: 1
bios: ovmf
boot: order=scsi0;ide2
cores: 16
cpu: x86-64-v3
efidisk0: Pool0:vm-100-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
ide2: none,media=cdrom
machine: pc-q35-10.2
memory: 16384
meta: creation-qemu=10.1.2,ctime=1768994644
name: [red]
net0: virtio=BC:24:11:85:C7:27,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win11
scsi0: Pool0:vm-100-disk-1,discard=on,iothread=1,size=96G,ssd=1
scsi1: Pool0:vm-100-disk-3,discard=on,iothread=1,size=220G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=[red]
sockets: 1
startup: order=4
tpmstate0: Pool0:vm-100-disk-2,size=4M,version=v2.0
usb0: host=072f:b100
vga: virtio,memory=256
vmgenid: [red]

An was es letztendlich gelegen hat können wir nicht sagen. Die alleinige Umstellung des Maschinentyps hat jedenfalls nicht gereicht.
Wir haben ebenfalls die Laufwerke von virtio zu scsi umgestellt und die Treiber sauber auf 271 gedowngraded.

Eine Datenbank in dieser VM hat wohl noch hohe Latenzen / Reaktionszeiten, hier kontaktiert der Kunde allerdings den Softwarelieferanten, da es ggf. nicht mit Proxmox zu tun hat.

Noch eine Anmerkung zum Schluss. Es kommt wohl stark darauf an, was in der VM läuft. Da der Kunde wohl noch eine andere Windows VM besitzt mit identischer Konfiguration wie initial, und diese läuft ohne Probleme. Allerdings läuft dort auch nur ein Veeam drin und keine Datenbanken.
Click to expand...
Was für eine DB ist das? Gerade aktuelle MS SQL haben gern alle CPU Features, daher würde ich bei MS SQL immer CPU Typ Host ohne Nested Virtualisierung nehmen.
Wenn du etwas mehr über deine Hardware erzählst, vor allem die Speicherkonfiguration, dann können wir besser abschätzen ob das gut für DB geeignet ist.
 
You must log in or register to reply here.
Top Bottom
Back