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

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.

Hi, teste mal bitte ob das auch auftritt, wenn du das Nested Virtualisierungs Flag auf der CPU entfernst.

Ich kann dieses Problem auch unter Windows Server 2022 nachvollziehen. Das Deaktivieren des nested-virt CPU-Flags hilft hier tatsächlich zuverlässig. Danke für den Tip!

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.