Proxmox 9 | Kernel 6.14 Performance Probleme Windows VM

Sebi-S

Sebi-S

Member
Proxmox Subscriber
Apr 19, 2022
54
8
13
Germany
Hallo zusammen,

ich habe bei einem aktuellen Cluster massive Performance Probleme mit Windows-Servern, die unter hoher TCP-Last stehen (200+ gleichzeitige Verbindungen).
Mit dem bisher eingesetzten Kernel 5.15 gab es die Probleme nicht. Die Performance stürzte massiv ab mit dem ersten 6.x Kernel.

Aktuell im Einsatz: Proxmox 9 mit Kernel 6.14, Windows Server 2022. Die Prozessoren des Host sind 2x Intel(R) Xeon(R) Gold 5317 (Ice Lake).

Das Problem macht sich nicht nur bemerkbar durch hohe CPU-Auslastung insgesamt. Sondern auch dadurch, dass die CPU in der VM höhere Auslastung meldet als Proxmox in der Übersicht der entsprechenden VM. So kommt es, dass die VM unter Windows eine Auslastung von 80% meldet, die Maschine laut Proxmox aber nur 40% Auslastung hat.

Wir haben bereits eine Menge probiert um die VM auf akzeptable Leistungswerte zu bringen.
Die aktuelle Konfiguration der VM:
+ CPU-Typ: host, NUMA: 1
+ Ballooning: 0
+ aktuelle QEMU Treiber

proxmox-ve: 9.0.0 (running kernel: 6.14.11-4-pve)
pve-manager: 9.0.10 (running version: 9.0.10/deb1ca707ec72a89)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.14.11-4-pve-signed: 6.14.11-4
proxmox-kernel-6.14: 6.14.11-4
proxmox-kernel-6.8: 6.8.12-15
proxmox-kernel-6.8.12-15-pve-signed: 6.8.12-15
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8.12-11-pve-signed: 6.8.12-11
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
proxmox-kernel-6.8.12-8-pve-signed: 6.8.12-8
proxmox-kernel-6.8.12-6-pve-signed: 6.8.12-6
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.8.12-2-pve-signed: 6.8.12-2
proxmox-kernel-6.8.8-4-pve-signed: 6.8.8-4
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5.11-8-pve-signed: 6.5.11-8
ceph: 19.2.3-pve2
ceph-fuse: 19.2.3-pve2
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx10
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.3
libpve-apiclient-perl: 3.4.0
libpve-cluster-api-perl: 9.0.6
libpve-cluster-perl: 9.0.6
libpve-common-perl: 9.0.11
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.1.8
libpve-rs-perl: 0.10.10
libpve-storage-perl: 9.0.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-1
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.16-1
proxmox-backup-file-restore: 4.0.16-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.0
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.2
proxmox-widget-toolkit: 5.0.5
pve-cluster: 9.0.6
pve-container: 6.0.12
pve-docs: 9.0.8
pve-edk2-firmware: 4.2025.02-4
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.3
pve-firmware: 3.17-2
pve-ha-manager: 5.0.4
pve-i18n: 3.6.0
pve-qemu-kvm: 10.0.2-4
pve-xtermjs: 5.5.0-2
qemu-server: 9.0.22
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve2
vncterm: 1.9.1
zfsutils-linux: 2.3.4-pve1
Linux HOST1 6.14.11-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-4 (2025-10-10T08:04Z) x86_64 GNU/Linux
Linux version 6.14.11-4-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-4 (2025-10-10T08:04Z)

CPU-Hardware (lscpu)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 52 bits physical, 57 bits virtual
Byte Order: Little Endian
CPU(s): 48
On-line CPU(s) list: 0-47
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Gold 5317 CPU @ 3.00GHz
CPU family: 6
Model: 106
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 2
Stepping: 6
CPU(s) scaling MHz: 82%
CPU max MHz: 3600.0000
CPU min MHz: 800.0000
BogoMIPS: 6000.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear pconfig flush_l1d arch_capabilities
Virtualization: VT-x
L1d cache: 1.1 MiB (24 instances)
L1i cache: 768 KiB (24 instances)
L2 cache: 30 MiB (24 instances)
L3 cache: 36 MiB (2 instances)
NUMA node(s): 2
NUMA node0 CPU(s): 0-11,24-35
NUMA node1 CPU(s): 12-23,36-47
Vulnerability Gather data sampling: Vulnerable
Vulnerability Ghostwrite: Not affected
Vulnerability Indirect target selection: Mitigation; Aligned branch/return thunks
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
VM 104 Config:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;ide0
cores: 24
cpu: custom-host-fix,flags=-md-clear;-spec-ctrl;+hv-tlbflush;+hv-evmcs;+aes
efidisk0: disc:vm-104-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: fileserver:iso/virtio-win-0.1.285.iso,media=cdrom,size=771138K
machine: pc-q35-10.0+pve1
memory: 64512
meta: creation-qemu=6.2.0,ctime=1659707897
name: Webserver2
net0: virtio=BC:XX:XX:XX:XX:15,bridge=15
net1: virtio=BC:XX:XX:XX:XX:3B,bridge=3B
net2: virtio=BC:XX:XX:XX:XX:EB,bridge=EB
net3: virtio=BC:XX:XX:XX:XX:2F,bridge=2F
net4: virtio=BC:XX:XX:XX:XX:49,bridge=49
numa: 1
ostype: win11
scsi0: disc:vm-104-disk-1,cache=unsafe,iothread=1,size=300G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=UUID-XXXX
sockets: 2
tpmstate0: disc:vm-104-disk-2,size=4M,version=v2.0
vmgenid: UUID-XXXX
Den cpu-typ custom-host-fix habe ich wie folgt definiert:
cpu-model: host-fix
flags -flush-l1d;-md-clear
reported-model host
 
  • Like
Reactions: refocus_mutt820
Frage, hast du in deinem Cluster unterschiedliche CPU Typen, wegen der angepassten CPU Einstellung ? Wenn nein würde ich die auf CPU:Host setzen um alle Features in der VM zu haben.
Dann steht da das du die aktuellsten virt-io Treiber, also Version 0.1.285, drin hast. Mach ein Downgrade die auf die 0.1.271. Die 285 macht unter Windows Probleme. Dazu gibt es einen Thread im englischen Forum.
 
coldenburg said:
Frage, hast du in deinem Cluster unterschiedliche CPU Typen, wegen der angepassten CPU Einstellung ? Wenn nein würde ich die auf CPU:Host setzen um alle Features in der VM zu haben.
Dann steht da das du die aktuellsten virt-io Treiber, also Version 0.1.285, drin hast. Mach ein Downgrade die auf die 0.1.271. Die 285 macht unter Windows Probleme. Dazu gibt es einen Thread im englischen Forum.
Click to expand...
Ich habe im englischen Forum nur Hinweise gefunden auf Probleme mit Windows Server 2025, ich nutze den Server 2022. Ein Downgrade probiere ich aber aus. Der Cluster hat gleiche CPUs, allerdings hatten wir in einem anderen Cluster bessere Performance mit CPU-Einstellungen wie x86_64v2-AES, v3 und v4.
Den aktuellen CPU-Typ habe ich, um sicherzustellen dass bremsende Mitigations auf jeden Fall deaktiviert werden.

Update:
Nach einem Downgrade auf 0.1.271 gibt es keine Unterschiede. Aus Kompatibilitätsgründen habe ich jetzt mal den Netzwerkadapter auf Intel E1000E umgestellt.
Was immer noch auffällt ist die CPU-Last. Die CPU-Last in der Windows VM wird doppelt so hoch angezeigt wie auf dem Host für die Maschine. Das habe ich auf den anderen Cluster-Nodes, die noch mit Kernel 5.15 laufen noch nie gesehen. Die Antwortzeiten auf meinem IIS-Webserver reagieren mit extremer Latenz, was ich auch nur auf dem Node mit Kernel >6.x habe. Das wiederum kann ich reproduzieren wenn ich die Windows-Appserver mit auf den aktuellen Node verschiebe.
 
Last edited:
Hi, das Problem habe ich auch noch nie gesehen. Bei AMD gab es mit NUMA letztens auch Probleme, hast du die Möglichkeit auf einem Host den 6.17er Kernel zu testen?
 
Falk R. said:
Hi, das Problem habe ich auch noch nie gesehen. Bei AMD gab es mit NUMA letztens auch Probleme, hast du die Möglichkeit auf einem Host den 6.17er Kernel zu testen?
Click to expand...
Da es ein Produktivsystem ist leider nicht ohne Umwege.
Der Punkt ist: zwar habe ich Proxmox 9 und Kernel 6.14 vorher in einer anderen Umgebung getestet. Aber die speziellen Auslastungsszenarien auf den IIS kann ich halt sonst nicht abbilden.
 
Sebi-S said:
Da es ein Produktivsystem ist leider nicht ohne Umwege.
Der Punkt ist: zwar habe ich Proxmox 9 und Kernel 6.14 vorher in einer anderen Umgebung getestet. Aber die speziellen Auslastungsszenarien auf den IIS kann ich halt sonst nicht abbilden.
Click to expand...
Ich habe auch VMs mit IIS bei Kunden, aber so ein Problem habe ich da auch noch nicht gesehen.
Das einzige was mir einfällt, ein Kunde hatte eine Applikation (keine Ahnung was) die nach der Migration von vSphere unbenutzbar langsam war.
Die haben ein neues Windows aufgesetzt und die Applikation umgezogen, seit dem ist alles schnell.
Das ist auch ein eher aufwändiger versuch, aber manchmal sitzt das Problem auch in der VM.
 
Falk R. said:
Ich habe auch VMs mit IIS bei Kunden, aber so ein Problem habe ich da auch noch nicht gesehen.
Das einzige was mir einfällt, ein Kunde hatte eine Applikation (keine Ahnung was) die nach der Migration von vSphere unbenutzbar langsam war.
Die haben ein neues Windows aufgesetzt und die Applikation umgezogen, seit dem ist alles schnell.
Das ist auch ein eher aufwändiger versuch, aber manchmal sitzt das Problem auch in der VM.
Click to expand...
Die VMs laufen seit Jahren und von Anfang an unter Proxmox. Und wie gesagt kamen die Probleme erst mit Kernel 6.x, weshalb die Maschinen bisher noch unter 5.15 liefen, was ja dauerhaft keine Perspektive ist.
 
Hast du eventuell auch die Virtual Hardware Version der VMs angepasst?
Ich hatte da schon mal Netzwerkprobleme mit einen SRV2016.
 
Mit der 0.1.285 hab ich unter Server 2022 ganz schlimme Netzwerkaussetzer gehabt. Bin dann wieder zurück zur 0.1.266. Aber es gibt ja schon ein paar PreWHQL. Warten wir mal ab.
 
Ob es nur ein verdacht ist oder ein Hinweis, das mag ich nicht zu beurteilen - ich schreibe nur, was ich damals zu VMWare-Zeiten gelernt habe.

Was mir als ersten fehlt: die Anzahl RAM deines Hosts. (Wenn du z.B. nur 128GB hast, wären es 64GB ansprechbar pro CPU bei symmetrischen Aufbau)

Dann hast du eine vCPU mit 24 Cores auf (augenscheinlich) eine CPU mit 12Cores gelegt. (Ja mit HT hast du 24Cores aber FPUs usw gibt's pro Core trotzdem nur einmal)

Durch diese Limitierung auf eine CPU erhältst du auch nur ein ansprechbaren NUMA-Node. (Das je nach RAM-Verfügbarkeit auch den gesamten RAM einer CPU bedeuten würde!)

... 1. Schritt: Anzahl vCores zurück drehen auf maximale Core-Anzahl der HardwareCPU und testen :: Wenn das keine Besserung bringt.

... 2. Schritt: (NUR wenn dein RAM <= 64GB pro CPU ist) 2vCPUs und je vCPU 6x vCores.


=> Ja Argumentation das es damals mit der Konfig lief ist nicht von der Hand zuweisen.............
 
Was die Cores angeht: Ja, ich hatte die VM zwischenzeitlich so konfiguriert dass sie 12 Cores von einem Socket bezieht und dann auf 2 Sockets hochgestuft = 24 vCores. Grundsätzlich hat die VM 10 oder 12 vCores pro CPU, das ist auch so eingestellt.
Der Node fährt mit 768 GB RAM, 384 pro Socket.

An der Stelle hakt es also nicht.
 
Ich weiß nicht, ob du "diese Stelle" vorzeitig außschließen darfst.
Könntest du dann bitte die NUMA-NODE Deklaration wieder raus nehmen?
Ich kenne diese Konfig nicht "CPU-Typ: host, NUMA: 1" VERMUTE aber, dass du damit nur NUMA-NODE1 ansprichst bzw. alles festlegst.

Mein NUMA-Voodoo-Verständnis nach, kann CPU0 doch gar nicht auf die Speichereinheiten von CPU1 zugreifen. Aber du nutzt beide CPUs in der VM.

Gibt es diesbezüglich Restriktionen im Linux Kernel 6.x? Es gab Änderungen, ob diese Auswirkungen haben - keine Ahnung. Es tut mir Leid, dass ich noch immer auf diesen Punkt reite.
https://kernelnewbies.org/Linux_6.0 2.0 -> Scheduler
Improve NUMA imbalance behavior.
Click to expand...

ggf.: sudo cat /sys/devices/system/node/node*/numastat
 
NUMA an sich wird hier nicht das Problem sein. Eher die Kombo aus Virtio-Queues über beide Nodes, dem default schlechteren Verteilen von IRQs unter Windows (Linux VMs machen das effizienter), höhere Latenzen durch den 6.14er Kernel und das alles wird verstärkt durch die Dual Socket Architektur.

Multiqueue würde ich testweise auf 4-8 reduzieren, RSS aktivieren und Kernel 6.8 oder 6.17 probieren.
 
  • Like
Reactions: Johannes S and Falk R.
cwt said:
NUMA an sich wird hier nicht das Problem sein. Eher die Kombo aus Virtio-Queues über beide Nodes, dem default schlechteren Verteilen von IRQs unter Windows (Linux VMs machen das effizienter), höhere Latenzen durch den 6.14er Kernel und das alles wird verstärkt durch die Dual Socket Architektur.

Multiqueue würde ich testweise auf 4-8 reduzieren, RSS aktivieren und Kernel 6.8 oder 6.17 probieren.
Click to expand...
Den Test einer Single-Socket Konfiguration und ggf. Kernel 6.17 kann ich noch einmal aktivieren. Stelle ich dafür um auf das Non-Subscription Repository?
Was die RSS Aktivierung angeht - wie gehe ich dafür vor?
 
Ja für den 6.17er Kernel auf no Subscription stellen und dann einfach apt install proxmox-kernel-6.17
 
Sebi-S said:
Ja, ohne Ergebnis, die VM verhält sich gleich.
Click to expand...
Da dort "nur" ein IIS läuft, könntest du mal versuchsweise eine neue VM mit IIS aufsetzen und die Daten rüber packen zum testen? Ich vermute das Problem irgendwo im Windows.
 
You must log in or register to reply here.
Top Bottom