Windows 2025 Freeze seit PVE 9.2.2

K

Khensu

Member
Proxmox Subscriber
Feb 3, 2023
71
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.
 
  • Like
Reactions: Johannes S
DrNoname said:
Ich hatte dasselbe Problem mit Freezes von Windows 11 pro VMs nach Update auf PVE 9.2.2.
Bei mir war es ausreichend, den cpu-Typ von "host" auf "x86-64-v2" umzustellen.
Click to expand...
Du weißt aber schon, dass Win11 mindestens x86-64v3 benötigt?
 
  • Like
Reactions: Johannes S
Wusste ich nicht, funktioniert aber trotzdem -> ich versuche, es mal umzustellen. Hast Du eine Idee, warum "host" als cpu-Typ nicht mehr funktioniert (die cpu ist ein Xeon von letztem Jahr)? Mittlerweile kam habe ich auf pve 9.2.3 upgedatet, vielleicht ist das Problem damit schon behoben.
 
Falk R. said:
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.
Click to expand...
Hallo @Falk R. ,

entschuldige die späte Antwort.

In dieser VM läuft:
MSSQL 2016 Express
MSSQL 2022 Express
PostgreSQL 13

Der Kunde beschrieb die Situation wie folgt:
===
Das Praxisarchiv funktioniert nicht wie gewünscht.
Die Vorschau und das Laden der Dokumente schlägt gelegentlich fehl, manchmal dauert auch einfach das Laden der Daten bzw. Dateien sehr lange.

Der Kunde arbeitet in Viertagewoche (Mo-Do) der letzte Ausfall war am Donnerstag 11.6. Letzte Woche funktionierte der Server ohne einen Ausfall.
Im Laufe der Woche werde ich den Softwarehersteller kontaktieren. Gemeinsam will ich mögliche Ursachen unter Windows bzw. in der Konfiguration der Software finden.
===

Host Specs:
CPU: INTEL(R) XEON(R) GOLD 6526Y
RAM: 128GB (4x32GB) DDR5-6400 ECC RDIMM

Die VM selbst ist auf einem ZFS Pool mit folgender Konfiguration:
# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Pool0 10.5T 4.40T 6.07T - - 17% 42% 1.00x ONLINE -
raidz1-0 10.5T 4.40T 6.07T - - 17% 42.0% - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -

Die RAIDZ1 Konfiguration könnte hier der Bottleneck sein...
Das wurde technisch von uns so so nicht abgesegnet. Normalerweise nehmen wir hier Spiegelkonfigurationen, 2 Disks pro vDEV. Besonders bei Datenbanken.

Hier müsste ggf. der Kunde in der VM feststellen, ob der Storage mit dem I/O nicht hinterherkommt.
=> Mit dem Softwarehersteller vermutlich nicht die verkehrteste Entscheidung.
 
Last edited:
DrNoname said:
Wusste ich nicht, funktioniert aber trotzdem -> ich versuche, es mal umzustellen. Hast Du eine Idee, warum "host" als cpu-Typ nicht mehr funktioniert (die cpu ist ein Xeon von letztem Jahr)? Mittlerweile kam habe ich auf pve 9.2.3 upgedatet, vielleicht ist das Problem damit schon behoben.
Click to expand...
Hi, v3 ist die Mindestvorgabe von Microsoft. Also kann es zu Problemen oder Abstürzen kommen, wenn die CPU die Features nicht alle hat. Aber wie immer bei MS, es kann.
Ich mache bei aktuellen Windows immer host und entferne das Flag Nested Virt. Damit habe ich bisher keine Probleme gesehen.
 
  • Like
Reactions: Johannes S
Khensu said:
Hallo @Falk R. ,

entschuldige die späte Antwort.

In dieser VM läuft:
MSSQL 2016 Express
MSSQL 2022 Express
PostgreSQL 13

Der Kunde beschrieb die Situation wie folgt:
===
Das Praxisarchiv funktioniert nicht wie gewünscht.
Die Vorschau und das Laden der Dokumente schlägt gelegentlich fehl, manchmal dauert auch einfach das Laden der Daten bzw. Dateien sehr lange.

Der Kunde arbeitet in Viertagewoche (Mo-Do) der letzte Ausfall war am Donnerstag 11.6. Letzte Woche funktionierte der Server ohne einen Ausfall.
Im Laufe der Woche werde ich den Softwarehersteller kontaktieren. Gemeinsam will ich mögliche Ursachen unter Windows bzw. in der Konfiguration der Software finden.
===

Host Specs:
CPU: INTEL(R) XEON(R) GOLD 6526Y
RAM: 128GB (4x32GB) DDR5-6400 ECC RDIMM

Die VM selbst ist auf einem ZFS Pool mit folgender Konfiguration:
# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Pool0 10.5T 4.40T 6.07T - - 17% 42% 1.00x ONLINE -
raidz1-0 10.5T 4.40T 6.07T - - 17% 42.0% - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -
ata-KINGSTON_SEDC600M1920G_[RED] 1.75T - - - - - - - ONLINE -

Die RAIDZ1 Konfiguration könnte hier der Bottleneck sein...
Das wurde technisch von uns so so nicht abgesegnet. Normalerweise nehmen wir hier Spiegelkonfigurationen, 2 Disks pro vDEV. Besonders bei Datenbanken.

Hier müsste ggf. der Kunde in der VM feststellen, ob der Storage mit dem I/O nicht hinterherkommt.
=> Mit dem Softwarehersteller vermutlich nicht die verkehrteste Entscheidung.
Click to expand...
Hi, gerade wenn eine DB etwas mehr Writes produziert, kann das in der Konstellation zu Latenzerhöhungen kommen und dadurch auch zu verzögerten Reads.
Ein MirrorPool wäre zu empfehlen. Du kannst ja mal schauen wie viel I/O Delay der PVE anzeigt, wenn es mal wieder langsam ist und wenn du auf der CLI nmon installierst und ausführst kannst du die Disks live überwachen. Wenn da 90% oder eventuell 100% Busy kommt, auch bei geringem Durchsatz, dann liegt es eindeutig an der Storagekonfiguration.
 
  • Like
Reactions: Johannes S
Falk R. said:
Hi, v3 ist die Mindestvorgabe von Microsoft. Also kann es zu Problemen oder Abstürzen kommen, wenn die CPU die Features nicht alle hat. Aber wie immer bei MS, es kann.
Ich mache bei aktuellen Windows immer host und entferne das Flag Nested Virt. Damit habe ich bisher keine Probleme gesehen.
Click to expand...
Vielen Dank für den Hinweis! -> ich versuche das demnächst mal...
 
Falk R. said:
Hi, v3 ist die Mindestvorgabe von Microsoft. Also kann es zu Problemen oder Abstürzen kommen, wenn die CPU die Features nicht alle hat. Aber wie immer bei MS, es kann.
Ich mache bei aktuellen Windows immer host und entferne das Flag Nested Virt. Damit habe ich bisher keine Probleme gesehen.
Click to expand...
Habe es jetzt ausprobiert, wie Du es vorgeschlagen hast: cpu: "host", nested-virt "aus" -> funktioniert -> vielen Dank!
 
Dass RAIDZ1 für die DBs suboptimal ist, sehe ich wie @Falk R., Mirror-vdevs sind da klar besser wegen der Write-Latenz, würd ich auch umbauen.

Aber bevor ihr den ganzen Pool anfasst: jetzt wo raus ist dass da MSSQL und PostgreSQL laufen, passt das ziemlich genau zu meiner Split-Lock-Vermutung von oben. DBs machen gern unaligned atomics, und solange split_lock_detect an ist bremst der Host bei jedem Trap die vCPU aus. Das ist aber gar keine Storage-Latenz. Häng dich mal mit dmesg -w drauf während die DB unter Last steht und schau ob da weiter traps reinkommen.

Falls ja: split_lock_detect=off testen, ist schnell gemacht und kostet nix. Bringt das bei den Reaktionszeiten was, war's das. Wenn nicht, weißt du dass es wirklich der Storage ist und der Mirror-Umbau der richtige Weg.
 
You must log in or register to reply here.
Top Bottom
Back