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?

@CGB Just refreshing XOA and the console didn't do it. I had to redeploy the XO appliance. Newer debian and binaries. export your config.toml and follow the steps like you are deploying a new xoa

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

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

@pierrebrunet Thanks.

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

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

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

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

Following up since the situation changed: QCOW2 went GA in XO 6.5 (released 2026-05-28), so the old ~2TB VHD ceiling is gone. A disk at exactly 2TB, and well beyond it, is fine now without shrinking to 1.99TB first. When acebmxer and john.c replied, it was still a release candidate; it's the stable story now. I haven't migrated a disk quite that size myself, so I won't promise it's totally painless, but the format limit that was blocking you isn't there anymore. The release blog has the details if you want to read up before the migration: https://xen-orchestra.com/blog/xen-orchestra-6-5/

Bit of a necropost on your necropost, but this got easier in XO 6.5. The REST API now accepts a txChecksumming parameter when you create a VIF (PR #9793, https://github.com/vatesfr/xen-orchestra/pull/9793), and it maps straight onto the ethtool-tx / other_config value you were setting by hand. So, for new interfaces, you can do it through /rest/v0 now instead of the XAPI script. I think it's on the create path rather than existing VIFs, though, so for the firewalls already running your script or the gear icon is probably still the way, and I haven't tested it against a live VIF myself. Either way, it's nice to have it native in the API now. All-Ki opened this pull request in vatesfr/xen-orchestra closed feat(rest-api): add support for txChecksumming and rateLimitting on V… #9793

Hi @r0123456789, GET /rest/v0/hosts/:id/stats is available in the REST API

Hi @dan89, It is possible to create an authentication_token using the REST API. POST /rest/v0/users/me/authentication_tokens

Hi @Steve_Sibilia, FYI, ACL V2 / RBAC is now available in the REST API. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.

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