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

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

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

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

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

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

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

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.

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