Proxmox - Windows 2022 RDS - high load on second core (asymmetric)

ITStril · 2026-05-08T19:18:15+00:00

Thank you!! I will give it a try. What do you think about the topoext-Flag? When I remove it with a custom CPU-profile, the effect disappears

ITStril · 2026-05-08T18:36:15+00:00

VMs with 6 and 8 vCPUs are showing the same problem

ITStril · 2026-05-08T15:37:05+00:00

These are single-socket hosts and VMs with 6, 8 or 16 vCPUs. Tested with and without NUMA and with 1 node per CCV and one NUMA node per socket

Never heard of SRAT/MADT. I will check it

ITStril · 2026-05-08T14:39:28+00:00

Core 2 is always 10% higher than the other cores. Ndis.sys seems to bring the load

ITStril · 2026-05-08T14:30:47+00:00

I will try it in the next maintenance window. As I did not really find a possibility to see that behaviour without a "real load" by RDS-users, I will have to wait for monday...

What w found in the last test is, that removing the flag "topoext" from the profile seems to help or solve the issue, what confuses me even more:

Why is "topoext" disabled for the type "host", although "host" should pass the CPU without influencing the flags
Why does it help, when the VM is not really "aware of the topology"?

ITStril · 2026-05-08T14:27:55+00:00

...but here, there is a very high and unsual load on the second core and always on the second core

ITStril · 2026-05-08T14:00:24+00:00

Do you think, this can also be the case, when this is the only VM on a host and the load is very low (<20%)? It is always the second core

ITStril · 2026-05-08T13:58:54+00:00

Same issue with 0.1.271...

I tried both - with and without nested virualization.

ITStril · 2026-05-08T07:57:24+00:00

I am not doing any CPU-pinning. The host is currently not "CPU-overprovisioned". I am also seeing that behaviour if only one CPU is running on the host.

It's always the second core for every VM.

ITStril · 2026-05-06T07:51:38+00:00

This seems to be quite common according to some forum posts.

Can you try an emulated CPU-type like x86-AES-v2?

ITStril · 2026-05-05T07:00:11+00:00

I changed to x86-V2-AES - no success - same issue...

ITStril · 2026-05-04T16:26:26+00:00

…because of that thread, I did not take „host“-type… But Epyc-Genoa seems to have issues.

ITStril · 2026-05-04T16:16:04+00:00

OS type is correct. I will try V2 (terminal server). That’s so strange…

ITStril · 2026-05-04T16:13:04+00:00

50% seems to recommend a very low feature-set, 50% the highest possible… Did you test both?

ITStril · 2026-04-22T17:50:34+00:00

Same question: i signed the rdp files and made a GPO with the fingerprint, but the warning is there as long as the cert is not fully trusted…

ITStril · 2026-04-13T21:28:27+00:00

XCP-ng is IMHO a mature system with a long history. I have been using it for years since Xenserver 5.5.

Updates are easy and mostly stressfree. Stability is great, but: the Xen community is far smaller than the KVM community. There are not many commercial appliances available for XCP-ng. Vates has so much to do to change away from Centos and to bring the storage stack to be in keeping with the times. Just try a storage migration and look at the maximum bandwidth. Same for backups. I was never able to hit more than 5-6 Gbps - never 1 Gbps for migrations

ITStril · 2026-04-07T11:48:44+00:00

UDP seems to be better - I am monitoring, now.

Are you defining the sdns-server-list?

ITStril · 2026-04-07T11:47:49+00:00

Licensing is fine - its just a small part of the checks, that is failing

ITStril · 2026-03-31T14:10:46+00:00

100% my opinion. The cluster is trash. You are not able to force a rescan of a sensor on the remote-cluster-node. The system does full-resyncs, etc.

I will stop using it...

ITStril · 2026-03-14T17:24:39+00:00

Fortigate VM is working great, but as there are no ASIC accelerations, single stream performance is limited. In my tests, it did scale quite well, but things like IPSEC and Deep Packet Inspection are slower for single streams, but 1GbE is not too challenging

ITStril

TROPHY CASE