@Andrew ok, thank you. This one indeed is not supposed to be triggered indeed.

@pierrebrunet I have updated my XOA and Proxies... It seems i did not see the warning on the next round of backups. Will continue to monitor now patches are installed.

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

@LucienLassalle Here's the output from the pool master. The xapi-pool-tls cert at least isn't empty. [image: 1780352392124-2c80406a-8398-45bc-aa49-ce16acae9912-image.jpeg] And it still appears to be valid [image: 1780352489651-0db145ec-4a02-41e2-9b82-aa79524ba966-image.jpeg] The xapi-ssl cert also looks correct and un-expired [image: 1780352594785-b2004ec3-cd55-4c4a-a9c8-58cb2f01deb2-image.jpeg] [image: 1780352645086-5e0a2bc4-54b7-42f1-ba54-5007f670550c-image.jpeg]

@poddingue Thank you kindly! Honestly, whatever organizational structure you think is best is fine by me.

Please disable HA and report if you still have the issue.

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

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

@poddingue Confirmed working, thank you so much for the heads-up, this made my day! Got it wired into the n8n flow and it's running perfectly. One gotcha for anyone else landing here, name_description gets rejected with a 422 "excess property", it has to be nameDescription. Working body: { "nameDescription": "nginx, app-1, app-2 | 2026-06-01" }

@Milenko if this is a definitive migration pathway for you, you can force start the replica VM, no problem, you can even delete the replica snapshot. Just disable the job at source, it will create a new replica VM otherwise if it is just a test boot of the replica, fast clone it, and start the fast clone (beware of double ip addressing while doing so... source VM should be halted, or replica clone should be started without network)

@Pilow Yeah, I'd run iostat and look to see how th resources are being limited, I'd run something like "iostat -dtkx 10" so you get extended stats every 10 seconds during that replication process and look at the wait, queue states, etc. to see if that helps identify any bottlenecks.

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

@dinhngtu said: I've taken a quick look, looks like it'll be solved as part of the Windows guest agent overhaul, so please look forward to that. Thanks for the info. I will be looking forward to that, indeed.

@florent Thanks for your reply! We have started to migrate thousands of VMs, so disk transfer speed is important for us.. We will also do our detailed tests soon with different threads setting and publish it here. I think threads=1 is a good and logical default, but not efficient. Others might complain if you set it to a higher value. Configuration option would be a real good solution.

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]