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

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

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

@olivierlambert It looks like I cant' use the VM from VMware option because it can't see that the dependencies are already installed. [image: 1780553211322-15293415-8c29-4081-bd19-eeee9ad90abe-image.jpeg] [image: 1780553274201-77805d17-0e05-4d7c-8e4a-175c9bc79c3f-image.jpeg] @acebmxer I use XO from sources on Debian 12. @edsilber I will try something before, and if it doesn't work, I'll do what you say. Thank you

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

@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

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

@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

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.

And how that change in architecture would disconnect you? Your SD-WAN is cutting the feed?

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

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

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

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