XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics

    • All categories
    • johnnezeroJ

      Tag-Based Automation: Manage VM CPU Priority via assigned tag.

      Watching Ignoring Scheduled Pinned Locked Moved Management
      24
      1 Votes
      24 Posts
      371 Views
      johnnezeroJ
      @john.c FYI: Bundling/done (Plugin/To come...)
    • LoTus111L

      Slow Backups | XOA Performance Test – Upgrading from 2 vCPU to 4 vCPU / 8GB RAM

      Watching Ignoring Scheduled Pinned Locked Moved Backup backup xoa performance
      5
      0 Votes
      5 Posts
      56 Views
      acebmxerA
      @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
    • rvreugdeR

      XOA vulnerabilty to "copy fail" and "dirty frag" bug

      Watching Ignoring Scheduled Pinned Locked Moved XCP-ng
      8
      0 Votes
      8 Posts
      344 Views
      R
      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.
    • acebmxerA

      Install XO from sources.

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      24
      3 Votes
      24 Posts
      3k Views
      acebmxerA
      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