@acomav it’s disappointing that there seems to be internal knowledge of:

(A) the issue with xcp-ng that triggers this problem but no one has shared the workaround in development to help us to fix it in xcp-ng

(B) the issue with XO failing to deal with this edge(?) case that was introduced in December still hasn’t been reverted.

I would have thought that if we were given the instructions for (A), someone could help with a patch for (B) or we’d just do it manually and (B) wouldn’t be needed.

If we have the information then we can help with the solution rather than feel like we’re living with a festering wound! Seems like a pretty important issue for enterprise software, and I haven’t heard that ‘if you pay money it will be quickly fixed’ - that’s both good and bad. I’d like to think it would be, but don’t want to feel like this community is a sales funnel either!

Anyway, xcp-ng and xo are a gift that I am very thankful for in my small business.

If the people on this thread can help in any way please let us know!

@Cyrille Thanks! Looking forward to using this, or something like this.

It would be awesome if there was a Youtube demo getting started video for yaml or typescript!

@Jonathon this is really nice to have shared, as we are looking to migrate from the RKE cluster we've deployed on bare-metal Xen to XCP-ng VMs to setup an RKE2 cluster to migrate to.

Will review this and probably have a bunch of questions!

@Danp I was going to do the upgrade over the December / January Christmas break in Australia but that is when this issue became apparent so we didn't want to be making major changes until it was resolved.

I note @anthoineb noted the first report was late August / September 2025 which was just before 8.2.1 reached EOL, so it would be a shame not to have a fix for it tested on 8.2.1 as it seems an upgrade to 8.3 would be unwise while we still have this issue?

@anthoineb python3 isn't on 8.2 by default. How do you recommend it be installed? I have avoided installing things directly, in compliance with the directions for xcp-ng.

@acomav it’s disappointing that there seems to be internal knowledge of:

(A) the issue with xcp-ng that triggers this problem but no one has shared the workaround in development to help us to fix it in xcp-ng

(B) the issue with XO failing to deal with this edge(?) case that was introduced in December still hasn’t been reverted.

I would have thought that if we were given the instructions for (A), someone could help with a patch for (B) or we’d just do it manually and (B) wouldn’t be needed.

If we have the information then we can help with the solution rather than feel like we’re living with a festering wound! Seems like a pretty important issue for enterprise software, and I haven’t heard that ‘if you pay money it will be quickly fixed’ - that’s both good and bad. I’d like to think it would be, but don’t want to feel like this community is a sales funnel either!

Anyway, xcp-ng and xo are a gift that I am very thankful for in my small business.

If the people on this thread can help in any way please let us know!

@anthoineb thanks very much! Definitely has us sharpening our cli skills in the meantime….

@florent Thanks, if there is something I need to do to coalesce the vdis to avoid disaster, that would be good to understand. I had been thinking it was just an XO issue that would not affect running vms and their vdis.

We have been quietly suffering without the time to try and resolve it for the past couple of months.

I have now spent the day trying to resolve it in our environment, as we have one SR having this problem with some hundreds! of vdi.

I am having the same problem whether running the docker container version of XO CE or the local install on a VM we've been using for ages.

It seems that the api call from the VDIs tab in v6 (Disks in v5) may be triggering a call to the wrong url, without the /rest/v0 prefix:

sudo journalctl -u xo-server -n 300 --no-pager

2026-02-26T06:01:57.169Z xo:rest-api:error-handler INFO [GET] /vms/[[UUID]]/vdis (404)

I had the same experience as some others for a while, a couple of months ago, where it would not show up in the v5 UI but was showing in v6, but very quickly after that it stopped working in either.

I know that these are VDIs with a snapshot in the chain, for example a parent VDI that may have two snapshots from it.

I had thought the issue may have something to do with https://github.com/vatesfr/xen-orchestra/pull/9381, as it was around this time that I saw the problem in v6 - but I see that this topic was started just before Christmas so there must have been something else too, perhaps that is when it emerged in v5 and this later patch then surfaced it in v6.

If I run curl with the /rest/v0 prefix to the url I don't get the 404.

I hope this helps to track it down!

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(rest-api): fix getVmVdis and enhance the type #9381

@Cyrille Thanks! Looking forward to using this, or something like this.

It would be awesome if there was a Youtube demo getting started video for yaml or typescript!

@Jonathon this is really nice to have shared, as we are looking to migrate from the RKE cluster we've deployed on bare-metal Xen to XCP-ng VMs to setup an RKE2 cluster to migrate to.

Will review this and probably have a bunch of questions!

@Forza There are various topics touching on how SMAPIv1 is a bottleneck here, eg: https://xcp-ng.org/forum/topic/9389/backup-migration-performance/8 - that's probably not the best example as it is also more on backups than migration!

@pdonias nice - so I gather we can delete from the 'server' settings the secondary host that we tried adding there, but is showing an error.

From what you say, I gather the 'pool connections' is for master servers of pools so there should just be one in the settings for each pool?