I liked as well. Easy to find the topics and good layout

@olivierlambert congrats to the team and also to this great community!

Kudos to XCP-ng team!

The incorrect clock results mean that Xen isn't in charge of frequency scaling management. Set the CPU Power Management to Performance Per Watt (OS) and run the previous xenpm, this time with a watch for real-time:

# watch 'xenpm start 1 | grep -i "avg freq"'

Start a VM boot storm (or a stress test inside one or more VMs) in order to generate some CPU load.

It's from the terminal/CLI. Alternatively, you can verify/change the boot options in /boot/grub/grub.cfg (for dom0 boot, see module2 /boot/vmlinuz entries).

Found this Citrix KB adding one more pci option, take a look:
https://support.citrix.com/article/CTX250121

@tbluml did you try the pci=realloc workaround, as stated in the RHEL link?

# /opt/xensource/libexec/xen-cmdline --set-dom0 pci=realloc

Edit: reboot the host after applying the change.

I liked as well. Easy to find the topics and good layout

@olivierlambert congrats to the team and also to this great community!

@cyrus104 said in XOA guest tools error:

Thoughts on some ways to fix this?

The problem was semantics... The command you really wanted was xe vm-cd-eject. Issuing a xe vm-cd-remove not only removes the .ISO but also the DVD-drive. In this case, you must recreate the device. It's possible to do so through the CLI, but it can be a bit tricky because it's needed to identify a free device position... IMHO the easier way is via XCP-ng Center:

Image from https://support.citrix.com/article/CTX132411:

@stormi Yes, after trying to save the changes, an error banner appeared with the message "Your account has been flagged". It was indeed a policy for new accounts, according to the github support team. I'll try again, thanks!

@stormi I've just created a github account but it was flagged right after trying to edit the wiki

Is there some sort of permission?

FYI, I couldn't edit the wiki without an account. The edit button only appears after signed in.

@enes-selcuk

This is one of our production servers with the CPU Power Management config I posted earlier. It's a Dell R730 - Xeon E5-2630v3 @ 2.40 Ghz. As you can see, some cores are boosting to 3.0-3.1GHz. The maximum for this CPU model is 3.2 GHz:

  Avg freq	2737140	KHz
  Avg freq	2737140	KHz
  Avg freq	2689120	KHz
  Avg freq	2665110	KHz
  Avg freq	2737140	KHz
  Avg freq	3097290	KHz
  Avg freq	3073280	KHz
  Avg freq	2713130	KHz
  Avg freq	2665110	KHz
  Avg freq	2641100	KHz
  Avg freq	2761150	KHz
  Avg freq	2665110	KHz
  Avg freq	2689120	KHz
  Avg freq	2617090	KHz
  Avg freq	2881200	KHz
  Avg freq	2785160	KHz
  Avg freq	2641100	KHz
  Avg freq	2713130	KHz
  Avg freq	2689120	KHz
  Avg freq	2689120	KHz
  Avg freq	2689120	KHz
  Avg freq	2785160	KHz
  Avg freq	2833180	KHz
  Avg freq	2761150	KHz
  Avg freq	2761150	KHz
  Avg freq	2905210	KHz
  Avg freq	2713130	KHz
  Avg freq	3025260	KHz
  Avg freq	2761150	KHz
  Avg freq	2713130	KHz
  Avg freq	2833180	KHz
  Avg freq	2617090	KHz

The incorrect clock results mean that Xen isn't in charge of frequency scaling management. Set the CPU Power Management to Performance Per Watt (OS) and run the previous xenpm, this time with a watch for real-time:

# watch 'xenpm start 1 | grep -i "avg freq"'

Start a VM boot storm (or a stress test inside one or more VMs) in order to generate some CPU load.

@enes-selcuk

What's the output of:

# xenpm start 1 | grep -i "avg freq"