Poor user experience with Windows Server 2025 on Proxmox

Last edited:
  • Like
Reactions: Johannes S
Are there any news here?
I have exactly the same issue as the OP describes: laggy UI elements like explorer and context menu with my Server 2025 VM's, while the Server 2022 are unaffected.

I checked out all the suggestions given here and in this thread - none has helped so far.

In contrast to the OP I have more modern hardware, in this case:
Code: 
CPU(s) 48 x AMD EPYC 9254 24-Core Processor (1 Socket)
Kernel Version Linux 7.0.14-15-pve (2026-08-26T14:21Z)
Boot Mode EFI
Manager Version pve-manager/9.2.11/f6997e698c7933ea
 
niteshadow said:
I am assuming this is a clean Windows Server 2025, with just virtio-win-guest-tools installed.
Can you post your VM configuration ?
Click to expand...

No, it is not clean generally. The image has some hardening settings applied.
Regarding running software, it is clean. No third party software is running on this test machine.

You are right, I should probably get my hands on a clean Server 2025 image and compare.
I would not have guessed that the hardening settings would cause an issue like that.

EDIT: I remembered, that there is another proxmox here on older machine. I will deploy this vm onto that machine and compare and report here.

Code: 
 ...:~# qm config 405
bios: ovmf
boot: order=scsi0
cores: 6
cpu: host
efidisk0: vm_nvme:vm-405-disk-0,efitype=4m,ms-cert=2023w,pre-enrolled-keys=1,size=1M
machine: q35
memory: 16000
name: Admin-Server
net0: virtio=BC:24:11:CC:D0:BA,bridge=vmbr0
numa: 0
scsi0: vm_nvme:vm-405-disk-1,iothread=1,size=250G
scsi1: vm_nvme:vm-405-disk-2,iothread=1,size=100G
scsihw: virtio-scsi-single
smbios1: uuid=69b5aa2b-c149-4efa-a0b6-df227e2296c5
sockets: 1
vmgenid: 7bf94186-cf30-41b2-af34-773e444ca82c
 
Last edited:
  • Like
Reactions: Johannes S
Looks like you have not enabled the QEMU Guest Agent, which I feel is important.You should also install all the guest tools.
Otherwise seems OK (but I personally don't use cpu "host" as I value portability). My recent Server 2025 conf:

Code: 
agent: 1
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 6
cpu: x86-64-v3
efidisk0: data:vm-740-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
ide2: none,media=cdrom
machine: pc-q35-11.0
memory: 16384
meta: creation-qemu=11.0.0,ctime=1783628049
name: pro2025
net0: virtio=BC:24:11:05:EC:6C,bridge=vmbr1,firewall=1,tag=20
numa: 1
onboot: 1
ostype: win11
scsi0: data:vm-740-disk-1,discard=on,iothread=1,size=160G
scsihw: virtio-scsi-single
smbios1: uuid=6f5b6dc4-9956-442d-968c-67ec693f63a6
sockets: 2
tpmstate0: data:vm-740-disk-2,size=4M,version=v2.0
vmgenid: f1193023-16fd-4996-a06c-c28084bc3159
 
elhannio said:
cpu: host
Click to expand...
there's your problem.

Host exposes the full set of cpu flags to the guest, which means all mitigations applicable to your cpu will apply. in a virtualized environment, mitigations will destroy guest performance- Windows most of all.

Additionally, Windows 11/2025 introduced hard feature dependencies for cpu support. Older CPUs (pre Haswell) do not have those features, which is why the official installer would not let you install on such hardware.

Depending on your use case, you have three choices:
1. use x86-64-V3 (or better) cpu type. this will mask your cpuid to prevent windows from activating mitigation code. its also possible to granularly control cpu features with a customized cpu type. the downside is that vulnerability mitigations would not be enabled, making this inadvisable for production use.
2. Upgrade your host hardware.
3. stick to older Windows kernels (windows10/2022)
(and obligatory 4) dont use windows.
 
  • Like
Reactions: andreworg, uzumo, ITT and 1 other person
after the joyous adventure of making the backup run on the pve 8.2.2 machine, I can say that the symptoms are still the same there.
The 8.2.2 hardware is this:
Code: 
CPU(s) 12 x Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (1 Socket)
Kernel Version Linux 6.8.4-2-pve (2024-04-10T17:36Z)
Boot Mode EFI
Manager Version pve-manager/8.2.2/9355359cd7afbae4
It's actually worse than on the bigger machine.
next thing: I will try to install a fresh windows server 2025 to rule out, that it is because of the hardening settings.
 
Last edited:
Just to make it a bit more clear and and a bit less subjective.
I am talking about the timespan from the 'mouse-up'-click to the full render of all elements of the windows-explorer.
These are the times:
Code: 
big host machine:
production-server    ws2022()            (quite idle)       >    0,15s
domain-server        ws2025(hardened)    (quite idle)       >    0,38s
fresh-install        ws2025()            (very idle)        >    0,43s
*admin-server        ws2025(hardened)    (very idle)        >    0,71s

small host machine:
*admin-server        ws2025(hardened)    (very idle)        >    1,17s

*this is the same image

This is just one symptom among others that describe the overall sluggishness of the 25ers.
I don't know... maybe this is normal for Server 2025?!
But I am seeing amounts of 'System Interrupts' in the 2025 vm's that doesn't seem to be okay, while amounts in the 2022 machines are just normal.

EDIT:
When I change the cpu type on the admin-server from x86-64-v2(AES) to host, it changes the system-interrupts in idle from 5-20% to around 1-7%.
However, it changes nothing for the above timings.
I changed these back and forth multiple times, because I know, that the system-interrupts also correlate to the workload - so possibly to all the random windows background processing going on.

Background:
We want to rollout new production software on multiple machines, and I just want to make sure that we start from a good base! I am absolutely not happy with the base currently.
 
Last edited:
I would like to try out the performance settings of the host hardware as someone mentioned as a solution here.
But there is no simple 'performance' power profile for our current cluster hardware, that would easily disable c-states.
It is an absolute jungle of options and I have not yet any idea what I should do there. It's a Gigabyte MZ33-AR1 with a AMD EPYC 9254
 
elhannio said:
It's a Gigabyte MZ33-AR1 with a AMD EPYC 9254
Click to expand...
That is a useful and potentially important bit of information. These CPUs are actually cpu clusters and are internally individual NUMA nodes. With 8 cores this is probably fine with NUMA disabled, BUT the memory situation could be impacted as off core memory access is orders of magnitude slower.

Is this a single or dual socket system (populated I mean.) How much ram is in the system, and how is it arranged (dimm count.)

I also went back and saw you had noted in the OP that running it on Nutanix (assuming Acropolis, not vmware) you did not have the same issues on the same hardware- it would be worthwhile to examing the vm config file since its also KVM/QEMU.
 
alexskysilk said:
That is a useful and potentially important bit of information. These CPUs are actually cpu clusters and are internally individual NUMA nodes. With 8 cores this is probably fine with NUMA disabled, BUT the memory situation could be impacted as off core memory access is orders of magnitude slower.

Is this a single or dual socket system (populated I mean.) How much ram is in the system, and how is it arranged (dimm count.)

I also went back and saw you had noted in the OP that running it on Nutanix (assuming Acropolis, not vmware) you did not have the same issues on the same hardware- it would be worthwhile to examing the vm config file since its also KVM/QEMU.
Click to expand...
Only one socket is populated. 4x32 GB of RAM with the colored slots populated:
1789025763973.png

About the nutanix thing: it was not me. You might have mixed something up?
 
At least I found the problem with the admin-server and the high amount of system-interrupts. It was something very basic.
I changed the OS-Type from 'other' to 'Microsoft Windows 11/2022/2025'. I simply overlooked it.
It has a massive impact on performance and the system-interrupts.

Code: 
Before:



CPU |  Usage |  User  | Kernel |  Idle
----------------------------------------
   0|  99.58%|   0.99%|  98.59%|   0.42%
   1|  99.53%|   1.02%|  98.52%|   0.47%
   2|  99.58%|   0.78%|  98.80%|   0.42%
   3|  99.58%|   1.30%|  98.28%|   0.42%
----------------------------------------

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1276887040 |       311740 |      20.30 |    5195.54 |    0.351 |     0.650 | D:\diskspd-test.dat (20GiB)
     1 |      1277382656 |       311861 |      20.30 |    5197.56 |    0.350 |     0.637 | D:\diskspd-test.dat (20GiB)
     2 |      1279881216 |       312471 |      20.34 |    5207.73 |    0.349 |     0.629 | D:\diskspd-test.dat (20GiB)
     3 |      1268699136 |       309741 |      20.16 |    5162.23 |    0.354 |     0.689 | D:\diskspd-test.dat (20GiB)
-----------------------------------------------------------------------------------------------------
total:        5102850048 |      1245813 |      81.11 |   20763.06 |    0.351 |     0.652

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       544305152 |       132887 |       8.65 |    2214.73 |    0.704 |     0.833 | D:\diskspd-test.dat (20GiB)
     1 |       545501184 |       133179 |       8.67 |    2219.60 |    0.702 |     0.803 | D:\diskspd-test.dat (20GiB)
     2 |       550649856 |       134436 |       8.75 |    2240.55 |    0.701 |     0.815 | D:\diskspd-test.dat (20GiB)
     3 |       544772096 |       133001 |       8.66 |    2216.63 |    0.705 |     0.841 | D:\diskspd-test.dat (20GiB)
-----------------------------------------------------------------------------------------------------
total:        2185228288 |       533503 |      34.73 |    8891.51 |    0.703 |     0.823

After:



CPU |  Usage |  User  | Kernel |  Idle
----------------------------------------
   0|  43.80%|   1.72%|  42.08%|  56.20%
   1|  43.33%|   1.98%|  41.35%|  56.67%
   2|  43.72%|   1.69%|  42.03%|  56.28%
   3|  44.87%|   2.01%|  42.86%|  55.13%
----------------------------------------

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      3274665984 |       799479 |      52.05 |   13324.58 |    1.480 |     0.457 | D:\diskspd-test.dat (20GiB)
     1 |      3262717952 |       796562 |      51.86 |   13275.97 |    1.485 |     0.519 | D:\diskspd-test.dat (20GiB)
     2 |      3265847296 |       797326 |      51.91 |   13288.70 |    1.481 |     0.441 | D:\diskspd-test.dat (20GiB)
     3 |      3263954944 |       796864 |      51.88 |   13281.00 |    1.484 |     0.466 | D:\diskspd-test.dat (20GiB)
-----------------------------------------------------------------------------------------------------
total:       13067186176 |      3190231 |     207.70 |   53170.25 |    1.482 |     0.472

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1398992896 |       341551 |      22.24 |    5692.49 |    2.077 |     0.594 | D:\diskspd-test.dat (20GiB)
     1 |      1398517760 |       341435 |      22.23 |    5690.55 |    2.082 |     0.636 | D:\diskspd-test.dat (20GiB)
     2 |      1403199488 |       342578 |      22.30 |    5709.60 |    2.080 |     0.566 | D:\diskspd-test.dat (20GiB)
     3 |      1401581568 |       342183 |      22.28 |    5703.02 |    2.077 |     0.556 | D:\diskspd-test.dat (20GiB)
-----------------------------------------------------------------------------------------------------
total:        5602291712 |      1367747 |      89.05 |   22795.67 |    2.079 |     0.589


These values are very similar now, to the result of the freshly installed Server 2025.
Settings are identical.

I also measured the click speed thing, and it is at 0,48s, which is in the area of the freshly installed Server 2025.

Maybe the sluggish gui feeling can't just be helped?! Maybe it is just slower than Server 2022.


This is the command line for the run of the diskspd.exe if someone wants to compare (just note that my host was really idle at testing time):
D:\diskspd.exe -c20G -b4K -d60 -Sh -L -o32 -t4 -r -w30 D:\diskspd-test.dat

I also created a logman performance counter along:
logman create counter VMPerf -o D:\VMPerf.blg -f bincirc -v mmddhhmm -max 500 -si 00:00:01 -c "\Processor(_Total)\% Processor Time" "\Processor(_Total)\% Privileged Time" "\Processor(_Total)\% Interrupt Time" "\Processor(_Total)\% DPC Time" "\System\Processor Queue Length" "\Memory\Available MBytes" "\Memory\Pages/sec" "\LogicalDisk(*)\Avg. Disk sec/Read" "\LogicalDisk(*)\Avg. Disk sec/Write" "\LogicalDisk(*)\Disk Reads/sec" "\LogicalDisk(*)\Disk Writes/sec" "\Network Interface(*)\Bytes Total/sec"

The whole command to create the two files would be:
logman start VMPerf ; D:\diskspd.exe -c20G -b4K -d60 -Sh -L -o32 -t4 -r -w30 D:\diskspd-test.dat | Tee-Object D:\diskspd-result.txt ; logman stop VMPerf ; Remove-Item D:\diskspd-test.dat
 
alexskysilk said:
there's your problem.

Host exposes the full set of cpu flags to the guest, which means all mitigations applicable to your cpu will apply. in a virtualized environment, mitigations will destroy guest performance- Windows most of all.

Additionally, Windows 11/2025 introduced hard feature dependencies for cpu support. Older CPUs (pre Haswell) do not have those features, which is why the official installer would not let you install on such hardware.

Depending on your use case, you have three choices:
1. use x86-64-V3 (or better) cpu type. this will mask your cpuid to prevent windows from activating mitigation code. its also possible to granularly control cpu features with a customized cpu type. the downside is that vulnerability mitigations would not be enabled, making this inadvisable for production use.
2. Upgrade your host hardware.
3. stick to older Windows kernels (windows10/2022)
(and obligatory 4) dont use windows.
Click to expand...
and yes, after testing with all cpu types - yes it is true that cpu=host also has a big negative impact on performance, so saying in my reply, that "it did not change anything" was incorrect.
I was just emotional because I cannot hear the advice "stick to old windows / don't use windows" anymore. If I could I would. If I could decide, all of our software stack would run on Linux.

This is the best setting I could find for our host hardware:

~# qm config 405
agent: 1
bios: ovmf
boot: order=virtio0
cores: 6
cpu: x86-64-v4
efidisk0: vm_nvme:vm-405-disk-0,efitype=4m,ms-cert=2023w,pre-enrolled-keys=1,size=1M
machine: pc-q35-11.0+pve2
memory: 16000
net0: virtio=BC:24:11:CC:D0:BA,bridge=vmbr0
numa: 0
ostype: win11
scsihw: virtio-scsi-single
smbios1: uuid=69b5aa2b-c149-4efa-a0b6-df227e2296c5
sockets: 1
virtio0: vm_nvme:vm-405-disk-1,iothread=1,size=250G
 
You must log in or register to reply here.
Top Bottom
Back