@pdonias confirmed... [image: 1780065202934-screenshot-2026-05-29-103255.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!

@acebmxer had a combo error on some VMs "fell back to full" and "not referenced by any backup" but no tranfer size either. can't screenshot it anymore, I did a rollback to XOA 6.3 for the time being, snapshoted just before the upgrade

@semarie I'll try to investigate to help you. Is it possible to run: stat /etc/xensource/xapi-pool-tls.pem openssl x509 -in /etc/xensource/xapi-pool-tls.pem -noout -text stat /etc/xensource/xapi-ssl.pem openssl x509 -in /etc/xensource/xapi-ssl.pem -noout -text (This file must exist; if not, I'd like the output of cat /etc/stunnel/xapi.conf.) And I'd like the same output for /etc/xensource/xapi-ssl.pem. If the certificate for /etc/xensource/xapi-pool.tls.pem has expired or it's empty, you can run: xe host-refresh-server-certificate host=$(hostname) If the certificate for /etc/xensource/xapi-ssl.pem has expired or it's empty, you can run: xe host-emergency-reset-server-certificate After running one of the two commands above, I recommend to do: xe-toolstack-restart (This should indeed restart the stunnel@xapi.service) I hope this helps.

@poddingue I am confused is how your updated articles can be accessed somewhere on my main Github page. I only see them if I follow your "pull" link. What needs to be done to commit them? Thank you!

Hi @andrew Can you provide some logs ? also assuming you have this issue in the "latest" branch only ?

Thank you all (@olivierlambert , @teddyastie ) for your valuable responses

@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. Switched back to Master branch and made some changes to my install script. add diagnostics for missing XO 6 web UI build artifacts Plain bash [[ -f ]] fails silently on unreadable paths owned by SERVICE_USER, causing false-positive missing-artifact warnings. Switch all file/dir tests and grep calls to use sudo. SUCCESS] Xen Orchestra built successfully [INFO] Build verification passed: dist — all JS chunks present. [INFO] Build verification passed: dist — all JS chunks present. [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: 0f29421627c7 v6 Dashboard still loading correctly. Thank you for the fix.

Because it works already better than the GO tool from Citrix… There's no urgent fix to do, I personally use it in my production since it's available. It's just less a priority for extra features because it's already ultra stable. Right now, we choose to work in priority on XCP-ng 9.0 than the Rust tools, we can't do everything at once yet.

@mdm Similar to the name-description parameter, the CLI ignores this parameter. The expected way to use would be to set the field value after the SR has been created. I'll make a work item to change the CLI and warn of ignored parameters so confusion like this doesn't happen

@pierrebrunet I inadvertently found more information yesterday. I installed an old e492b commit on a new machine, configured identically to the original, and got a different error but the same effect. The new error is: xcp xo backup Error: read ETIMEDOUT That lead me to this page: https://xcp-ng.org/forum/topic/10799/backup-timeout-error I moved the XO machine onto the same subnet as XCP, leaving the storage behind in a different network. This fixed the issue, at least on commit e492b ... I have not yet tried it on the new release... however I am pretty confident it will be successful. If I'm honest, I think this is a tuning issue between XO and XCP. XO is now mounting an NFS share across this subnet boundary and that mount is not having any sort of performance issue, but for some reason XO times out transferring the same data from dom0? That seems off to me. It's not a probem moving XO to the other subnet, so I've done that, but maybe this deserves a look in the future.

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

I'm waiting for veeam 13.1 release as well. Will move a few things over and test out the native backup in the meantime.

It hurts (4y ) but I'm glad we finally managed to get what you needed!! Thanks for posting a comment in here after all this time [image: 1779991585587-21cd8648-f61e-46d9-a52f-4ec55a7b7c8b-image.jpeg]

@yllar I'm not sure honestly (I will have to ask the rest of the team), but anyway, even if it were fixed by latest xen package, we still didn't publish a new installer ISO with the fix. Target is still around June for the new ISO. Regards, Yann

@abudef An overhaul of the guest agent is coming. We're considering adding some kind of update notifications as part of that overhaul, but it'll take some time to suss out the details. Autoupdating the Xen drivers is potentially disruptive and I'd prefer avoiding outages arising from an update coming at a bad time.

@maximsachs Thanks for getting back to me on this. I think (and hope) that in the mean time we will have released an official new ISO that fixes the issue you are having. So, you will be better off testing the new official ISO rather than this unofficial one I'll try to ping here when the new official ISO is out. Thanks! Regards, Yann

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

Still, something to fix