I updated XO again - just thought I would add the API error details: Error: ENOENT: no such file or directory, open '/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/7b86306a-fffa-4528-b946-d0bc60dcb609/20260527T000011Z.vhd' From: at NfsHandler.addSyncStackTrace (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:21:26) at NfsHandler._openFile (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:154:35) at /opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:29:26 at new Promise (<anonymous>) at NfsHandler.<anonymous> (/opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:24:12) at loopResolver (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:83:46) at new Promise (<anonymous>) at loop (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:85:22) at NfsHandler.retry (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:87:10) at NfsHandler._openFile (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:103:18)

@semarie Maybe this points at an issue. It looks like the cert file is empty? And this is after I ran that command to refresh the cert. I get this same output for both the pool master and the host I am trying to add. [image: 1779888222308-84fc3624-7777-4f6a-b81f-c09586a63d05-image.jpeg] Then the openssl x509 command says it's unable to load the cert or read it. I assume that's because it's empty? As for the time and date, yes the pool master and this server are in sync. At first, I had forgotten to set the new host to use the NTP pool during setup and Xen Orchestra helpfully yelled at me about that. Haha

i2c error seems related to (I guess) a RGB controller that is presumably controlled by something else (or maybe not usable/non plugged). But it's harmless unless you are looking to configure RGB (but I don't think you want to do that anyway). EFI_MEMMAP warning is probably because Dom0 doesn't see UEFI mappings, as it relies on a different method to do UEFI calls. This is expected and this warning doesn't indicate a problem. The latest error is likely related to the first one. what I will miss /won't be able to do vs a user that has not these messages? (otherwise, why they would be raised) Nothing meaningful. if these messages /failures have an impact on the time during which the machine is booting? (it seems the load process is hanging for about a minute) No. if these messages /failures are officially documented somewhere? For the EFI_MEMMAP, XenServer has a article on it stating the same as me : https://support.citrix.com/external/article/CTX331542/citrix-hypervisor-82-efi-efimemmap-is-n.html how can I resolve these failures, because failures are failures... even if "one should not worry about them"? You may be able to hide it, like by blacklisting i2c and such, but TBF it's not worth the time.

@florent said: @acebmxer back to work thank you for yor patience and help on this. I feel that it's not the same issue , with abrupt increase W will try our best to also fix this one Yes i replied to ticket also.... Yes you can do what is needed to XOA. Just looked at memory and it dropped.... [image: 1779875710969-screenshot_20260527_055458.png]

@simonp said: @acebmxer Hi, Thanks to your help we were able to identify an issue with Redis that we think is the source of the v6 dashboard loading issue. Could you try and checkout the fix_redis_encryption_issue branch, rebuild xo and restart ? This should solve the 401 issues. Will continue to test but i think that did resolve it. I am hesitant from the logs after update. I have refreshed the page 20 times and still loads correctly no glitches. [INFO] Detected package manager: apt [INFO] Checking for updates... [INFO] Installed commit: fc4d34b354e3 [INFO] Remote commit: e5210ad478b8 [INFO] New version available. Proceeding with update... [INFO] Checking for active Xen Orchestra tasks before updating... [INFO] Using authentication token from xo-config.cfg... [INFO] Querying active tasks as authentication token... [SUCCESS] No active tasks found. Proceeding with update... [INFO] Task check performed by: authentication token [INFO] Stopping xo-server service... [INFO] Preserving API token ("xo-installer") [INFO] Flushed browser session token (client_id y7iutpmvys7) [INFO] Deleted stale collection index: xo:token::indexes [INFO] Preserving API token ("no description") [INFO] Flushed 1 session token(s) — users will need to log in again [INFO] Preserved 2 API token(s) — third-party integrations unaffected [INFO] Creating backup of current installation... [SUCCESS] Backup created: /opt/xo-backups/xo-backup-20260527_094604 [INFO] Cleaning old backups (keeping 5)... [SUCCESS] Old backups cleaned [INFO] Pulling latest changes... Updated 3625 paths from the index remote: Enumerating objects: 182, done. remote: Counting objects: 100% (91/91), done. remote: Compressing objects: 100% (31/31), done. remote: Total 182 (delta 63), reused 76 (delta 58), pack-reused 91 (from 1) Receiving objects: 100% (182/182), 103.02 KiB | 6.87 MiB/s, done. Resolving deltas: 100% (104/104), completed with 31 local objects. From https://github.com/vatesfr/xen-orchestra fc4d34b35..dae64be80 master -> origin/master + 4c172c569...d4ed13417 feat/sdn-controller/improve-startup-perf -> origin/feat/sdn-controller/improve-startup-perf (forced update) * [new branch] fix_qa_test -> origin/fix_qa_test * [new branch] fix_redis_encryption_issue -> origin/fix_redis_encryption_issue * [new branch] lite/warning-before-leaving-XOA-deploy -> origin/lite/warning-before-leaving-XOA-deploy * [new branch] mel/acl/pool-RBAC-check -> origin/mel/acl/pool-RBAC-check 2ca9e58d1..24506cfa6 mel/acls/pbds-RBAC-check -> origin/mel/acls/pbds-RBAC-check * [new branch] refacto/migrate-to-register-rest-routes -> origin/refacto/migrate-to-register-rest-routes + 761fb851c...766311798 xo6/general-tab-traffic-rule-vif -> origin/xo6/general-tab-traffic-rule-vif (forced update) de5fc9cc4..a10ed619a xo6/traffic-rules-vif -> origin/xo6/traffic-rules-vif branch 'fix_redis_encryption_issue' set up to track 'origin/fix_redis_encryption_issue'. Switched to a new branch 'fix_redis_encryption_issue' [INFO] Node.js v24.15.0 satisfies configured version 24 — no runtime change needed [INFO] Installing Node.js 24... [INFO] Node.js 24 requirement satisfied (installed: v24.15.0) [INFO] npm is available: 11.12.1 [INFO] Installing Yarn... [INFO] Yarn is already installed: 1.22.22 [INFO] Building Xen Orchestra (this may take a while)... [INFO] Sufficient swap space available: 4095MB [INFO] Clearing build cache for clean rebuild... [INFO] Moderate memory detected (5399MB RAM + 4095MB swap). Limiting build concurrency to 2. yarn install v1.22.22 (node:87888) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities. (Use `node --trace-deprecation ...` to show where the warning was created) [1/5] Validating package.json... [2/5] Resolving packages... success Already up-to-date. $ husky install husky - Git hooks installed Done in 0.57s. yarn run v1.22.22 $ TURBO_TELEMETRY_DISABLED=1 turbo run build --filter xo-server --filter xo-server-'*' --filter xo-web --filter @xen-orchestra/web --filter @xen-orchestra/backup-archive --concurrency=2 ╭───────────────────────────────────────────────────────────────────────────╮ │ │ │ Update available v2.9.12 ≫ v2.9.14 │ │ Changelog: https://github.com/vercel/turborepo/releases/tag/v2.9.14 │ │ Run "yarn dlx @turbo/codemod@latest update" to update │ │ │ │ Follow @turborepo for updates: https://x.com/turborepo │ ╰───────────────────────────────────────────────────────────────────────────╯ • turbo 2.9.12 WARNING no caches are enabled • Packages in scope: @xen-orchestra/backup-archive, @xen-orchestra/web, xo-server, xo-server-audit, xo-server-auth-github, xo-server-auth-google, xo-server-auth-ldap, xo-server-auth-oidc, xo-server-auth-saml, xo-server-backup-reports, xo-server-ipmi-sensors, xo-server-load-balancer, xo-server-netbox, xo-server-openmetrics, xo-server-perf-alert, xo-server-sdn-controller, xo-server-test-plugin, xo-server-transport-email, xo-server-transport-icinga2, xo-server-transport-nagios, xo-server-transport-slack, xo-server-transport-xmpp, xo-server-usage-report, xo-server-web-hooks, xo-web • Running build in 25 packages • Remote caching disabled (remote cache requested — set TURBO_TOKEN and TURBO_TEAM, or run "turbo login" and "turbo link") Tasks: 35 successful, 35 total Cached: 0 cached, 35 total Time: 48.025s Done in 48.47s. [SUCCESS] Xen Orchestra built successfully [WARNING] XO 6 web UI (@xen-orchestra/web/dist) was not built — browser will use XO 5 UI at /v5. [WARNING] This may be caused by unmet peer dependencies (pinia 3.x, vue-router 5.x). [WARNING] Access your XO instance at: https://<host>/v5 until the upstream issue is resolved. [INFO] Creating systemd service... [SUCCESS] Systemd service created and enabled [INFO] Configuring sudo for xo-service (mount/umount/findmnt)... [SUCCESS] Sudo configured for xo-service (mount, umount, findmnt) [INFO] Applying security hardening... [INFO] Starting xo-server service... [INFO] Waiting for Xen Orchestra to become ready (up to 60s)... [INFO] Not ready yet (attempt 1/10), retrying in 6s... [SUCCESS] Xen Orchestra is ready (HTTPS on port 443) [SUCCESS] Update completed successfully! [INFO] New commit: e5210ad478b8 [SUCCESS] Xen Orchestra built successfully [WARNING] XO 6 web UI (@xen-orchestra/web/dist) was not built — browser will use XO 5 UI at /v5. [WARNING] This may be caused by unmet peer dependencies (pinia 3.x, vue-router 5.x). [WARNING] Access your XO instance at: https://<host>/v5 until the upstream issue is resolved. [image: 1779875491511-screenshot_20260527_055115-resized.png] [image: 1779875500570-screenshot_20260527_055051-resized.png]

@olivierlambert Thanks again for your input and recomendations! I'll verify that this is solved by having the LUN expanded to 8GB instead. Afterwards I'll mark your answer as the solution!

@tjkreidl My pleasure.

@laszlobortel since we are generating the stream sequentially, we though that there wasn't any real world gain. Also, if my understanding is correct using one thread means we will have only one process( + xo + nbdkit-vddk) processes , and we were trying to limit the risk of zombie process locking the disks , which was far too common with the previous code we'll do a quick test to ensure it does not beak anything and propose either a better default of a configuration option note that this will be a concurrency per disk, so VM with a lot of disk will put more pressure on the source

@tsukraw I think the bottleneck is indeed the tapdisk and smapiv1. We have full 10Gb WDM between nominal and DR site, and get the same transfer speeds as you on CR. [image: 1779779566351-c860aa15-c649-4608-91f9-0cec88645218-image.jpeg]

When speaking to our Veeam sources, we were told end of July is the target date for 13.1. That is what we are hoping for as Veeam is an important one for us.

Still, something to fix

@tjkreidl I found that some Intel PRO GPU card have SRV-IO without any additional license, but this functionality is supported in Linux kernel 6.12 and up. I hope in new XCP-NG will have 6.12+ and support GPU sharing.

@iams3le we have switched to the signed xcp-ng drivers. We also replaced our older 2022 servers.

Hello all, Version 9.1.200 Release of the Windows PV tools has been released. Download the latest release here: https://github.com/xcp-ng/win-pv-drivers/releases It will be integrated into the XCP-ng built-in tools ISO after a test period of 2 weeks. This release brings bug fixes and improvements to the PV drivers. Changes since 9.1.146/9.1.152 Improved: Update XSTDVGA to v0.1.124.1151; add extra resolutions Fixed: Better compatibility with Xen block backends with large sector sizes Fixed: Fix more network unplug issues Improved: Driver optimizations

@MajorP93 that’s fine - I never use ballooning anyway so I guess I am covered good

@Rod-G These have 9.4.2-xxxx and I need to go through and update everything now that I see how far behind I am. the second VM completed fine after its reboot, something was just stuck in a dirty state and got in the way of the import or health check.

I'm not positive, but this may be available RSN in xo-lite.

@Danp I was going to do the upgrade over the December / January Christmas break in Australia but that is when this issue became apparent so we didn't want to be making major changes until it was resolved. I note @anthoineb noted the first report was late August / September 2025 which was just before 8.2.1 reached EOL, so it would be a shame not to have a fix for it tested on 8.2.1 as it seems an upgrade to 8.3 would be unwise while we still have this issue?

@tonyp90 great, thanks !