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

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

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

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

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.

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

Another confirmed data point, with package delta and the specific malformed field. Host: XCP-ng 8.3.0, xapi 26.1 (build 26.1.4), Xen 4.17.6-9. Setup: XO from sources (community). All VDIs vanished from the per-VM Disks tab (XO 5 and XO 6); xe and the SR Disks tab show them fine; VMs run normally. Trigger was the 8.3 host update + reboot this morning — XO build unchanged since May 28, disks visible yesterday. Host update delta (today): all 26.1.3-1.10 → 26.1.4-3.1 (xapi-core, xenopsd, sm-cli, sm-fairlock, xapi-storage-script, vhd-tool, message-switch, etc.), plus sm 3.2.12-17.8 → 17.9 as an independent bump. The malformed field. An affected live OS disk (VM running): is-a-snapshot: false snapshot-of: <populated, points to another VDI> snapshot-time: <populated> A normal base VDI should have an empty snapshot-of. After the update, snapshot-of/snapshot-time are populated on real, non-snapshot base VDIs, and XO filters anything with a non-empty snapshot-of out of the per-VM Disks view — which is the disappearance. The VDI that snapshot-of points to is a legitimate base image in my environment (a heavily-reused Win2022 build template with a large genuine snapshot/clone lineage), so I can't tell from the host side whether the parentage links themselves changed or only the snapshot-of on live VDI labeling did. Either way, the consumer-visible effect is the same. REST confirms: /rest/v0/vms/<uuid>/vdis → []; /rest/v0/vdis/<uuid> → "no such VDI" for the VBD's referenced UUID, while xe vdi-list shows it. Caution for others: since live disks now carry snapshot-like metadata, be careful with Health-dashboard "orphan" cleanup and snapshot deletion on affected VMs until this is understood. Workaround that restored the per-VM Disks view: snapshot → revert → delete-snapshot (tested on a powered-off VM, immediate). Happy to provide more diagnostics. Quick Follow-up: Additional symptom, same root cause: ISO-SR VDIs are also affected. Pre-existing ISOs disappeared from the XO ISO picker (only ISOs uploaded after the patch still show). An affected ISO's vdi-param-list shows: is-a-snapshot: false snapshot-of: 937c3945-... (same anchor UUID as an affected VM disk on a different SR) snapshot-time: 19700101T00:00:00Z (Unix epoch — clearly synthetic) Notably the spurious snapshot-of on both an ISO VDI and an unrelated VM OS disk points to the same anchor UUID, with an epoch timestamp — so this looks like the update is stamping pre-existing VDIs with a bogus snapshot-of rather than any real lineage. VHD chains/GC are clean (GC reports no work).

@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

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

Hi @halvor, FYI, ACL V2 / RBAC is now available in the REST API. You can create a privilege that only give you read privilege on your host. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.