@tjkreidl said: @john.c Not found with the Wayback Machine, alas. Still not finding it anywhere else, but will keep looking! It's a crying shame Citrix didn't preserve the treasure trove of old community blogs. I did a bit of digging with the aid of AI and I’ve managed to uncover the original three blog posts of NUMA and references to UMA. If you do some more digging you may be able to uncover the rest, so it can be rewritten and/or updated, then be hosted somewhere that won’t go down so easily, or be lost as easily. If you do an update or write etc, may I suggest switching the images used to WebP or AVIF format, will seriously help file size while maintaining their quality (or even giving room for higher quality). Consider switching to SVG for diagrams rather than raster (or as the default). I’d suggest checking out to consider using Mermaid for diagrams (https://mermaid.ai/open-source/?utm_medium=hero&utm_campaign=variant_a&utm_source=mermaid_js). Maybe if you do a rewrite use markdown and something like Hugo, to generate it from the files to host on GitHub or some other pages providing repository (e.g. GitLab Pages or Codeberg Pages). https://web.archive.org/web/20220527221535/https://www.mycugc.org/blogs/tobias-kreidl/2019/03/07/tale-of-two-servers-bios-settings-affect-apps-gpu https://web.archive.org/web/20220527213026/https://www.mycugc.org/blogs/tobias-kreidl/2019/04/30/a-tale-of-two-servers-part-2 https://web.archive.org/web/20220527215004/https://www.mycugc.org/blogs/tobias-kreidl/2019/04/30/a-tale-of-two-servers-part-3 https://community.citrix.com/forums/topic/235895-xenserver-vm-citrix-worker-sizing-question/ https://xcp-ng.org/forum/topic/9359/cpu-provisioning https://community.citrix.com/forums/topic/237493-memory-and-cpus-assigning-to-vms-in-order-to-obtain-maximum-performance-according-to-numa-topology/ https://community.citrix.com/forums/topic/241553-bios-power-performance-settings/ https://community.citrix.com/forums/topic/243640-citrix-hypervisor-performance-tips/

@Pilow said: @LoTus111 nice, but could be better you're missing the additionnal step in the TIPS section here : https://docs.xen-orchestra.com/xo5/troubleshooting#memory upgrading XOA to 8Gb is not enough, you have to tell xo services to be able to use this additionnal RAM. Question is if XO is built with 6gb initially does one still need to addjust memory via the command? Or only if expanding after the fact? Edit - to answer my own question and for others. After adding this function to my script it does appear the XO will setup appropriately with deployed with 6gb ram initially. ============================================== Xen Orchestra Memory Allocation ============================================== Setting Value ----------------------------- ----------------------------------- Total system RAM 5399 MB Current xo-server heap limit 4887 MB Recommended heap limit 4887 MB

Quick update now that Vates has published their official advisory. First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts. VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng. Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated. One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says. VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/ Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester A kernel patch from Vates is in progress. Apply as soon as it lands.

Made some updates to this project. Any existing users please see note. I have also updated the initial post. ️ Upgrading from an earlier version of this script? Read this first. This version bumps the config schema to v2 (adds PUBLIC_URL and ENCRYPT_REDIS_CREDENTIALS) and corrects two config.toml generation bugs. Your xo-config.cfg is migrated automatically and non-destructively, but the corrected /etc/xo-server/config.toml is only written by --reconfigure. Run --reconfigure once before resuming normal updates: ./install-xen-orchestra.sh --reconfigure This regenerates config.toml with the fixes (your old file is backed up first; data in /var/lib/xo-server is untouched). It is strongly recommended if you set both REDIRECT_TO_HTTPS=true and REVERSE_PROXY_TRUST — that combination previously produced a duplicate [http] section and silently dropped one of the settings. Afterwards, run --update as normal for routine XO updates — --update does not need to be preceded by --reconfigure again. Also added option to adjust Xen Orchestras memory allocation. Useful if you are getting out of memory errors or added more memory to XO. ============================================== Xen Orchestra Memory Allocation ============================================== Setting Value ----------------------------- ----------------------------------- Total system RAM 5399 MB Current xo-server heap limit 4887 MB Recommended heap limit 4887 MB

Ping @Team-XO-Frontend

Hi, Let me ping @Team-Storage