Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    rzrR
    @MajorP93 said: @rzr Since the targeted test window is over by now, I wonder: what are your plans regarding this set of patches? Will it be released soon? yes this is the plan, we're a bit slower this time because the iso publication is a longer process, but afaik no issue are spotted so far, thank you for your patience.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    T
    @ataxyanetwork , just checking in on this. No rush at all. Thanks!
  • 3k Topics
    29k Posts
    acebmxerA
    @danp Just check with AI to make sure this was not cause my install script.. Here is the report it came back with... ` It's an upstream issue in Xen Orchestra itself — neither this project nor the installer scripts are at fault. I traced the exact cause: What's happening The "Failed to fetch latest master commit" message comes from XO's own web UI (the About page). It's defined upstream in xo-web's messages.js and displayed when the page can't retrieve the latest master commit. That check runs in your browser: the About page calls fetch('https://api.github.com/repos/vatesfr/xen-orchestra/commits/master') directly from the client (see _callGithubApi in xo-web/src/common/xo/index.js). On 2026-07-22, upstream merged PR #10101 — "feat(xo-server): add content security policy" (commit 8e8afeb, a few hours before de9687e). It makes xo-server send a default CSP header with default-src 'self' and no connect-src directive — so browsers now block the About page's call to api.github.com. This explains every symptom in the forum thread: it appeared right at de9687e (the first commit most people landed on after the CSP merge), rolling back fixes it, rebuilding on latest master brings it back, and the installer script itself still fetches commits fine — the CSP only affects the browser, not server-side git. No one has filed an upstream issue for this yet — only the original PR exists. It would be worth reporting on vatesfr/xen-orchestra (the fix is for them to add connect-src 'self' https://api.github.com to their default CSP, since source installs need it for the update check). Workaround until upstream fixes it The PR's design lets config values extend the default CSP (array values are concatenated onto the defaults): Open /etc/xo-server/config.toml (where this project's installer writes the config). Add this section: [http.helmet.contentSecurityPolicy.directives] connect-src = ["'self'", "https://api.github.com"] Restart xo-server: sudo systemctl restart xo-server. Reload the About page (hard refresh, Ctrl+Shift+R) and verify the master commit shows again. If you'd like, I can add that CSP directive to this project's config generation so fresh installs and rebuilds get it automatically — say the word and I'll make the change. Sources: xcp-ng forum thread, PR #10101, xo-web About view source
  • Our hyperconverged storage solution

    49 Topics
    782 Posts
    M
    Hello, Indeed this is a known issue with XOSTOR, when causing a sync of too many resources at once it's possible for a DRBD resource to leak memory during the resync. A patch on the 9.2.18 fixes this by throttling the number of resources that can be synced at once to mitigate the issue. The 9.2.18 update should be in the main xcp-ng-linstor repo very soon. What you can do too is give more RAM to the dom0 of your hosts. How many RAM have been allocated to dom0 at the moment? We advise 16GB or 32GB depending on the number of volumes.
  • 36 Topics
    117 Posts
    B
    Merci beaucoup pour vos retours ! @nathanael-h : C'est l'étape suivante !!! J'ai découvert cluster API le mois dernier et j'ai déja testé sur d'autres plateforme ! ça déchire !!! Je ne savais pas qu'il y avait un support de XCP-ng ! Je finis ma série d'article pour une installation classique et je bascule sur cluster API ! @ataxyanetwork Merci pour ton repo. Je vais regarder ça