Hello, not sure I can actually help, but I'll try to bring some info. As far as I know, Xen handles the cpu scaling by default, as you checked with xenpm. Therefore I would guess it does not expose the p-states to the guest. When reading /proc/cpuinfo the kernel will call show_cpuinfo() function will call arch_freq_get_on_cpu() which ends up checking support for p-states on fallback to a simpler version that will in our case probably always report the base clock. At least that's my understanding, I went through this quickly and may have missed bits, but sound "logical" to me. I think the guest tools won't help you there, they report information from host to guest only, and as mentionned in the first point the guest frequency reporting is not live frequency. The only way I see how to confirm your VM is using turbo clocks would be to pin your VM vcpus to fixed pcpus, load the VM and check these pcpu with xenpm as you were doing. It is interesting to me you're seeing turbo clocks there at all, from my tests for some other stuff, on epyc I actually never saw the clock go above the base clock, did you do anything specific to enable it? I guess BIOS setup to enable turbo, and maybe enable it with xenpm?

haha sure you should, well deserved!

@capo I'd also add here that if you go with the Citrix tools they aren't "just" from Windows Update, you'll need to actually run the installer either way, the drivers can be kept up to date via Windows Update but still have to install the agent so you can properly control/manage the VM. I personally say go with the Citrix if you need secure boot, right now I believe you can't secure boot VMs with XCP-ng tools installed. Unless that changed and I somehow never saw news about that.

No problem FYI the update is now available: https://xcp-ng.org/forum/post/70029

You should ask on XenDevel Matrix channel: https://xenproject.org/help/matrix/

Hi ! @m4x116 I have same issue from last two days, its your problem is solved then please explain why this issue occurred and solution of this problem.

@apattyn Hmmmm I wonder if some of this comes down to ARC's immaturity, I have a 2060 passed through to a Ubuntu VM that is in UEFI mode and it works flawlessly for GPU rendering in the VM. So don't think using BIOS should be a requirement, but I am also not as familiar with Fedora so I could be missing something.

@tuxen I did send the MEMORY.DMP-files to a microsoft specialist and did post the result on Juli 25 in that thread. daemon.log is quite hard for me to read. I did not find something, I can see as an error. It looks, like a "shutdown" - not a reboot. @chrisfonte Yes, fully licensed. It is not a "shutdown because of missing licenses after 24h".

@Hightmar Excellent to see, yeah this worked well for me on the 2060 and have been using it on Jellyfin for a while now without any crashes or other odd behavior.

@olivierlambert This is great news. Looking forward to testing this functionality on a xcp-ng server in the future:)

@olivierlambert Hello, Because we want to install Linstor on three hosts for HA, can I set those VM doesn't failover? Thanks

@stormi Thanks, Stormi.. Looming forward to beta or when it becomes more publicly available. Long story short, I have a Win11 VM that I have stuck on a dieing server and cant migrate it off anywhere with the vTPM enabled.. LOL

You are welcome! Enjoy XCP-ng and Xen Orchestra

Perfect! Enjoy

@tuxen Thank you! I will try it

Many thanks @gduperrey I disable Dell repo.

@robyt It depends on (1) licensing, if any, as some licenses go by cores vs. sockets, and (2) NUMA/VNUMA depending on how critical the performance is depending on how the VCPUs get allocated between sockets or on a single socket. Best way IMO is to try all and test with benchmarks. See, for example, this article and the previous two articles, as well as articles by Frank Denneman and others: https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

@Toni said in XCP-ng host restarts at random intervals: Please check whether something is connected via USB on the systems that have the reboot problem. Hi! It's a community forum here So it's a bit more up to you to demonstrate the bug by investigate a bit more and digging the logs, otherwise if you want an investigation on your setup, then pro support is more fit. If you want to take a look on what logs to check, take a look at https://docs.xcp-ng.org/troubleshooting/