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

@ZaphodB I have the same experience some 2.5yrs later - I don't know why there isn't some more clarity in XO as to what and when you should add a machine as a "Server" under settings. When I installed XCP-NG on my second 'host' it joined the pool but wasn't added in XO as a "Server".

@Meth0d thanks for sharing your experience. Fortunately I was able to just hit "Convert to HVM" after my imported PV failed to reboot after upgrade from 20.04 to 22.04 - was all set to load a livecd etc too!

@stevewest15 that is a shame! Thanks for sharing!

Were you able to work it out? I have a 32GB RAM domU that keeps failing migration between nodes unfortunately!

@john-c I am seeing an option for Migration compression in XO, under Xen settings on the Advanced tab for a Pool of 8.2.1 servers. Haven't tried it though.

@olivierlambert thanks for investing in this. Great news!

@olivierlambert this is a concern for me with moving to 8.3 - having a bunch of VMs just migrated from Xen with PV. I understand 8.3 doesn’t support PV and potentially some older operating systems. Will there be a page of supported OS / Distribution versions or have I just not looked hard enough for one that’s already there?

@olivierlambert thanks, my comment wasn’t meant as a criticism. I appreciate all you share so freely in both software and in the forums! Just was wondering how another user got on.

I have benefitted immensely thanks to Xen on bare metal over the years and while some people push towards KVM, I found the import process to XCP-NG very smooth once I got python2 built on the Debian12 dom0s that have served so well.

rdiff-backup was a really solid backup method for us using LVM snapshots and iscsi, so it’s just taking some time to get used to the GUI and the new CLI - and that the CLI can help resolve things stuck in the GUI. Your forums and personal posts are gold.

Automated boot testing after a backup is fantastic.

Thanks for everything!

@CodeMercenary Great question! Similar situation here. Sorry you didn't get a response.

What did you end up doing?

@mauzilla we've been running iscsi based backups with our previous 'bare metal' Debian Xen system, thanks to rdiff-backup. It worked really well for our purposes and I am still a bit uncomfortable with XO / XCP-ng backing up over a 1Gbps link. Hopefully a 10Gbps link will resolve that.

Have you considered using ZFS replication with TrueNAS as part of your backup strategy?

@mauzilla sounds like we are doing similar things! I gather you're now running TrueNAS Scale as we are? We decided to go with RC2 of Electric Eel since there's been some big architecture changes between 24.04 and 24.10.

We are just running it through testing and have run into performance issues for backups to an NFS target and I was interested to read the huge gain in speed you got from moving to iSCSI.

I was thinking of seeing if we can backup to an iSCSI target while keeping many of the VMs on NFS. Have you tried this and had any success?

@mauzilla It's been a few years, but this seems like a common issue. How have you worked around it?

@olivierlambert Thanks! Just read this and after experimenting with dynamic memory I see what you mean!

@nikade thanks for the ideas of where to look!

In my case we're testing and just have a 1Gb link between these hosts, which is what I was putting it down to.

This particular VM is a freshly migrated PV from Debian Xen with:

Memory limits (min/max)
Static: 16 MiB/16 GiB
Dynamic: 8 GiB/16 GiB

Could that Dynamic setting be the problem because as I recall it reduces the VM to 8 on migrate, so when doing the migrate perhaps 8 isn't enough for the VM?

I will try changing it to 16/16 and see if that has any noticeable impact. Thanks!