@johnnezero The full HTML versions will render much better. The PDF conversion is less than perfect. iIll try to get those uploaded, as well.

Thanks for that information. I will make this message short because @stormi is busy but I want to say thanks to Vates and XCP-ng for all their work done to support Windows on the Xen platform. This includes TPM2 and secure boot support and Microsoft-signed pv drivers. Well done!

I just cant give up..... Update — narrowed this down, and I think it's a token-indexing issue, not auth tokens being "deleted." Background: this XO (from-source install) was built fresh and then had a config restored into it from an exported XO config backup. After the config import. I logged out as admin@admin.net and logged into my user account and then deleted the admin@admin.net account. Here is what I've been able to prove: Symptom: Every browser session token fails immediately after login. Seconds after logging in, xo-server logs: xo:redis WARN The id xo:token:<id> had no attached entries. …and then the v6 dashboard's REST/event calls all return 401: [GET] /dashboard (401) [GET] /vms (401) [GET] /hosts (401) [GET] /srs (401) [GET] /backup-logs (401) [GET] /pools/<uuid>/stats (401) [POST] /events/<uuid>/subscriptions (401) What I tested / ruled out: Not a stale browser cookie. Fully closed the browser, logged in fresh. The brand-new token (visible in Settings → Tokens, created at login time) reproduces had no attached entries within ~40 seconds. Not the reverse proxy. Reproduced on a direct connection to the XO server, no proxy in the path. (v6 does appear to load somewhat better direct vs. proxied, but the token warnings + 401s happen either way.) Not stale Redis index data. I stopped xo-server, deleted xo:token::indexes (it's a Redis SET), and restarted — three separate times. XO rebuilds the key, but every newly-issued session token re-triggers the warning. Only session tokens are affected. API tokens created via Settings → Tokens (with a description) work perfectly — they authenticate fine against the REST API via the authenticationToken cookie and never log this warning. The breakage is specific to browser-login session tokens. My read: on this restored-from-config instance, xo-server issues a session token at login but cannot resolve that same token on the next request — it looks like the token body is written but its index entry is not (or the xo:token collection's index schema is in a state XO can't self-heal after a config import). API tokens are unaffected, which is why integrations keep working while the v6 dashboard 401s. Likely trigger: restoring an exported XO config onto a fresh install. The imported state and the xo:token collection appear to end up inconsistent. Questions for the team: Is there a supported way to fully rebuild the xo:token collection index on a restored instance, beyond deleting xo:token::indexes? Is this a known issue with config-backup restore leaving the token store inconsistent? Happy to provide full logs or run diagnostics. ❯ journalctl -u xo-server -f | grep -iE 'had no attached|WNSCG|401' May 22 00:50:12 xo-ce xo-server[42654]: 2026-05-22T00:50:12.370Z xo:rest-api:error-handler INFO [GET] /users/0344d88b-0fe8-4462-811b-5c04a92981aa (401) May 22 00:50:12 xo-ce xo-server[42654]: 2026-05-22T00:50:12.507Z xo:rest-api:error-handler INFO [GET] /dashboard (401) May 22 00:50:17 xo-ce xo-server[42654]: 2026-05-22T00:50:17.166Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries. May 22 00:50:27 xo-ce xo-server[42654]: 2026-05-22T00:50:17.166Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries. May 22 00:50:27 xo-ce xo-server[42654]: 2026-05-22T00:50:27.399Z xo:rest-api:error-handler INFO [GET] /srs (401) May 22 00:50:30 xo-ce xo-server[42654]: 2026-05-22T00:50:30.201Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries. May 22 00:50:30 xo-ce xo-server[42654]: 2026-05-22T00:50:30.201Z xo:rest-api:error-handler INFO [GET] /backup-logs (401) May 22 00:50:32 xo-ce xo-server[42654]: 2026-05-22T00:50:32.176Z xo:rest-api:error-handler INFO [POST] /events/5f61024f-480a-4673-aa87-1a13512804c4/subscriptions (401) May 22 00:50:34 xo-ce xo-server[42654]: 2026-05-22T00:50:34.807Z xo:rest-api:error-handler INFO [GET] /backup-logs (401) May 22 00:50:39 xo-ce xo-server[42654]: 2026-05-22T00:50:39.429Z xo:rest-api:error-handler INFO [POST] /events/b305b71b-1fb7-4dbd-ae1b-dd55ecf658c9/subscriptions (401) May 22 00:50:39 xo-ce xo-server[42654]: 2026-05-22T00:50:39.530Z xo:redis WARN The id xo:token:WNSCGIpaCV0zihqsT3L3lXMkwA6XWcTgoSmzfHXT5xM had no attached entries. May 22 00:50:44 xo-ce xo-server[42654]: 2026-05-22T00:50:44.445Z xo:rest-api:error-handler INFO [GET] /hosts (401) May 22 00:50:44 xo-ce xo-server[42654]: 2026-05-22T00:50:44.447Z xo:rest-api:error-handler INFO [GET] /vms (401) May 22 00:50:49 xo-ce xo-server[42654]: 2026-05-22T00:50:49.522Z xo:rest-api:error-handler INFO [POST] /events/3e83a79d-9386-4c36-801a-292734a05051/subscriptions (401) May 22 00:50:50 xo-ce xo-server[42654]: 2026-05-22T00:50:50.730Z xo:rest-api:error-handler INFO [GET] /hosts/00fcd37d-e4c4-476e-a0ef-1ded027bebf8/alarms (401) May 22 00:50:52 xo-ce xo-server[42654]: 2026-05-22T00:50:52.242Z xo:rest-api:error-handler INFO [POST] /events/3e83a79d-9386-4c36-801a-292734a05051/subscriptions (401) May 22 00:52:40 xo-ce xo-server[42654]: 2026-05-22T00:52:40.784Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries. May 22 00:52:43 xo-ce xo-server[42654]: 2026-05-22T00:52:43.994Z xo:rest-api:error-handler INFO [GET] /pools/939ed551-fbd6-9868-52d8-d3997b7bf7da/stats (401) May 22 00:52:45 xo-ce xo-server[42654]: 2026-05-22T00:52:45.872Z xo:redis WARN The id xo:token:Gy-WhZLuY-C5zmPLqx677VA9uP_v6G8_ZY8IsyPoBfo had no attached entries. May 22 00:52:47 xo-ce xo-server[42654]: 2026-05-22T00:52:47.710Z xo:rest-api:error-handler INFO [GET] /pools/939ed551-fbd6-9868-52d8-d3997b7bf7da/stats (401)

Thanks for the ping and for narrowing it down; that live-migration repro is a really useful signal. I don't know enough about how the guest tools report IPs back through XAPI to say where the canonicalisation should happen, but it sounds like something @Team-Hypervisor-Kernel might want to look at since the trigger is on the agent side after migration. If it turns out to be reproducible on another Windows guest version (2022, 2019), that might help narrow it further; no pressure though, you've already done the hard part.

@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?

Dug a little deeper. For a VM where the disks are not shown the following XO API call fails: /rest/v0/vms/a519e879-3971-9210-51b6-7df14336e7b7/vdis { "error": "no such VDI ac37700d-3157-4df7-b8e8-e1799a994591", "data": { "id": "ac37700d-3157-4df7-b8e8-e1799a994591", "type": [ "VDI" ] } } Also the VDI cannot be retrieved over the XO API: /rest/v0/vms/a519e879-3971-9210-51b6-7df14336e7b7 ... "$VBDs": [ "4ea8a3cd-0d1b-dc60-4d9c-fd70e060f06c", "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba" ], ... /rest/v0/vbds/9f4ca686-9fc2-35a9-c3e9-c871c9f68aba { "type": "VBD", "attached": false, "bootable": false, "device": "xvda", "is_cd_drive": false, "position": "0", "read_only": false, "VDI": "ac37700d-3157-4df7-b8e8-e1799a994591", "VM": "a519e879-3971-9210-51b6-7df14336e7b7", "id": "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba", "uuid": "9f4ca686-9fc2-35a9-c3e9-c871c9f68aba", "$pool": "93d361b7-f549-53b7-a3aa-c9695bf0abe4", "$poolId": "93d361b7-f549-53b7-a3aa-c9695bf0abe4", "_xapiRef": "OpaqueRef:1d424d94-f540-2eb4-9e52-2a9b21ec0a19" } /rest/v0/vdis/ac37700d-3157-4df7-b8e8-e1799a994591 { "error": "no such VDI ac37700d-3157-4df7-b8e8-e1799a994591", "data": { "id": "ac37700d-3157-4df7-b8e8-e1799a994591", "type": "VDI" } } However the VDI can be listed using the xe cli: $ xe vm-list uuid=a519e879-3971-9210-51b6-7df14336e7b7 uuid ( RO) : a519e879-3971-9210-51b6-7df14336e7b7 name-label ( RW): XXX power-state ( RO): halted $ xe vbd-list vm-uuid=a519e879-3971-9210-51b6-7df14336e7b7 uuid ( RO) : 4ea8a3cd-0d1b-dc60-4d9c-fd70e060f06c vm-uuid ( RO): a519e879-3971-9210-51b6-7df14336e7b7 vm-name-label ( RO): XXX vdi-uuid ( RO): <not in database> empty ( RO): true device ( RO): xvdd uuid ( RO) : 9f4ca686-9fc2-35a9-c3e9-c871c9f68aba vm-uuid ( RO): a519e879-3971-9210-51b6-7df14336e7b7 vm-name-label ( RO): XXX vdi-uuid ( RO): ac37700d-3157-4df7-b8e8-e1799a994591 empty ( RO): false device ( RO): xvda $ xe vdi-list uuid=ac37700d-3157-4df7-b8e8-e1799a994591 uuid ( RO) : ac37700d-3157-4df7-b8e8-e1799a994591 name-label ( RW): XXX Disk 0 name-description ( RW): Created by XO sr-uuid ( RO): 977b7e63-bb84-57b2-3e0d-206afea553bf virtual-size ( RO): 34359738368 sharable ( RO): false read-only ( RO): false Seems almost like something changed in the XCP-ng API which XO cannot consume.

@pkgw I tested it with a cluster size of 2 megabytes. I got similar results to those with the default size.

Ah excellente nouvelle Je passe le sujet en résolu !

@MathieuRA I noticed you merged https://github.com/vatesfr/xen-orchestra/pull/9787 I just tried it. And it does seem to fix my original issue! Thank you! I am always impressed by you guys. Making testing and reporting upstream (to you guys) a good experience! Elise-FZI opened this pull request in vatesfr/xen-orchestra closed fix(xo6): remove dev routes from prod #9787

@vlamincktr XO PROXY from source is pretty reliable at no cost either use @acebmxer script or @ronivay here is a quick tuto on an ubuntu VM https://omnibox.huducloud.com/shared_article/QJ9y1bRSPj9VTbWp6NKaV7yn/installation-xoa-a-partir-des-sources-github-ronivay first part is XO CE, second part is XO PROXY CE beware as you delegate some jobs to XO PROXY, to ever upgrade XO PROXY when you upgrade XOA, so that they have the same backup mechanisms/code

@florent said: where does this disk comes from From my Redhat 10 @florent said: if you have access to your SR from the outside, you can also put the qcow2 file directly I create a VM to be a NFS to access the 3 HDs, the qcow disks are on the Redhat 10 that I was trying to import from. Do you mean I put the qcow disks on one of the HDs and access them when I create a VM?

@tonyp90 great, thanks !

@pierrebrunet sorry for the delay in responding... I scored some time out of the office. Before replying, I rebuilt the XO server using the latest version and created a new backup identical to the last. Just wanted to be sure this issue wasn't fixed... I've attached the log. 2026-05-20T21_41_04.958Z - backup NG.json.txt

the last rewrite of the stream processing ( spring 2025 ) focused on stability and memory footprint, and , on a standard cpu, it tops at around 300MB/s per backup job. Your benchmarks are very interesting, and they confirm most of it. this limit was not really an issue since, in most case the xapi was limiting around 100MB/s per disk , but it will be more a more visible limit Note that master have some fixes on the memory usage (not related to backups) That's why we have started an internal workforce focused on performance, with all the teams from the kernel to the backups, including storage, network and xapi. If I can brag a little : [image: 1779106650898-afd7b59b-a4f0-4a92-88ee-2c7ba52d18bf-image.jpeg] i9 , nvme disk , backup to a nvme disk in passthrough, xoa and vm are on the same host, so it's quite far from real world data, but it shows where the limit is

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.

@julienXOvates Excellent, thanks for looking at this Julien! Rob

@dthenot said: @ccooke Hello, You should be able to make the XOSTOR SR work again if you update sm and sm-fairlock on the other hosts. yum update sm sm-fairlock Then you should be able to re-plug the SR on the master and proceed with the RPU. Hello, Had the same problem, the command resolved the issue. It needs to be run on every host. Everything is working fine again. However, I had to complete the pool update manually.

@ducatijosh did you do a yarn build ?