@pierrebrunet Thanks.

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

Hi, everyone Thank you for your help. I had a flux that was blocked by our firewall. The button worked after that. But it doesn't explain why I lost this configuration and had to reinstall it. Thanks again.

@LucienLassalle Interesting. I'm not sure I was all the way up to date when I upgraded to 8.3 and it's possible I was a month or two behind. I only upgraded because I ran across a need for the virtualized TPM support (which is cool to see implemented!). Thanks again for all the effort in looking at this!

@Andrew I did suspect that would be sufficient, but we need to think at feature level, and as mentionned there is no such thing we could do "quickly" for linux and other OSes. I anyway did a brain dump of my investigation before posting my previous message and we do now have an entry in the roadmap for it, which was not the case previously.

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

Nice detective work with iperf. I think that single-stream-versus-parallel result points at the link rather than XOA, and it matches what @Pilow saw (same CR speed on a much fatter 10 Gb path). On your multi-stream question: as far as I understand it, the transfer is a single stream per disk, which is exactly why a per-stream cap on your circuit hurts so much, though I'm honestly not certain of the internals. The one lever I'd try is NBD with multiple connections per VDI, which you can switch on under Advanced settings (https://docs.xen-orchestra.com/xo5/incremental_backups#nbd-enabled-backups); in principle, that opens several connections for the same disk, so it might get you past a single-stream limit, though I can't promise it beats your ISP's per-stream shaping. For a definitive answer on whether the data mover can parallelise per disk, it's probably one for @Team-XO-Backend. Either way, glad it's narrowed down to the link.

Maybe you can check for a bigger timeout on your UDM?

@LucienLassalle — Thanks Lucien, appreciate the detailed reply. Glad we landed on the same result independently, and the CI/testing rationale makes complete sense — stability matters more than rushing a same-day patch. Good to see June Updates #1 out covering Fragnesia, ptrace_may_dream, and Pintheft, and good to know CIFSwitch will likely be treated the same way. I'll keep checking the blog and the VSA registry. And noted on security@ for future reports. Thanks for the great work as always.

Hello. Thank you for your input. I am aware, that this is more of a warning message, than a error. I´m just trying to figure out, what is my best way to go here. My plan was: Setup a repljob for the vm in a lets say hourly interval On the day of the migration, shutdown the vm and start the last replication manually Disable the cr job Start the replicated vm on the new pool, check it and if all is ok, use it as new vm, otherwise start the old vm. The documentation says "If you want to start a VM on your destination host without breaking the CR jobs". Tbh i dont care about breaking the job. If everything works fine, i dont need it anymore, if not, i can setup a new job pretty fast. I was just wondering, if the new vm will stay in "blocked mode" for ever. Kind regards

@acebmxer Yeah, it does not show up as an available device in XOA or XCP-ng Center. Just listed when running lspci

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

@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

Maybe, the view from hypervisor level would be interesting, too: # xenstore-ls -f | grep -i driver Will list the drivers for each domain. # list_domains Gives the VM UUID for each domain id.

After building new xo with root and more testing, I have come to this conclusion... Both things are true, and they're in tension The official docs prefer non-root for the long-running service — that's a least-privilege hardening recommendation for the daemon. Normal XO (UI, backups, hosts, VMs, NFS/CIFS remotes) works fine non-root. But several XO features assume root anyway. The ESXi/VMware import "install from source" buttons are hard-coded to refuse unless id -u == 0. You already hit this same pattern once before — the credential-encryption/XenStore work (commit 5e8b7fd) existed precisely because non-root broke that too. So "everything fails non-root" isn't quite it — what fails is the specific subset of features XO wrote assuming it runs as root. Each one needs a separate workaround. The import button is one that cannot be worked around for a non-root process: it's a uid check on the running daemon, full stop. The honest trade-off You can pick at most two of these three: Service runs non-root (docs' preference) In-app "install nbd from source" button works Script doesn't pre-install packages The button (#2) requires the daemon to be uid 0. So: Want the button to work → run that box as SERVICE_USER=root. Simplest, everything XO ships just works, zero manual steps. You give up the non-root hardening. Want to stay non-root → the button is permanently dead; the only way to get import working is the binaries being placed by root once (script or by hand). The binaries run fine as non-root — only their installation needs root. My recommendation Use SERVICE_USER=root on this box. XO's own codebase keeps assuming root (import, and you already saw it with encryption/XenStore), so non-root is a recurring fight against upstream for marginal hardening. Root is fully supported, it's what the official XO appliance ships, and it makes the buttons you want work with no manual package steps. Keep non-root only if hardening that box is a hard requirement and you're fine never using the in-app import installer.

@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" }

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

@pdonias confirmed... [image: 1780065202934-screenshot-2026-05-29-103255.png]