VDI not showing in XO 5 from Source.

andrewperry

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

florent

@andrewperry hi this is an identified issue on xapi / storage side
this commit is making it visible .

Pinging @anthoineb here for more info

andrewperry

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

bogikornel

@florent The following error occurred:

Mar 16 18:38:10 XOA xo-server[4001]: 2026-03-16T17:38:10. 246Z xo:rest-api:error-handler INFO [GET] /vms/0691be81-7ce9-7dba-9387-5620f8e0c52f/vdis (404)

XO version: Master, commit 15917
xcp-ng version: 8.3 with the latest updates.

What’s interesting is that there are two xcp-ng servers, and the problem only occurs on one of them.

anthoineb

@andrewperry Hi, we are working on 2 things:

a proper fix under development to avoid new issue where snapshot-of field is garbage.
a script to fix the wrongly set snapshot-of already present on affected pools.
Both are necessary and we hope we can release the script soon to at least workaround if the issue happen again before we release the fix.

Pilow

@anthoineb wow great news ! still impacted by this issue

andrewperry

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

wgomes

Just ran the update on Xen today and still have the same problem. "no itens found" when I go to see the disks tab.

Pilow

@wgomes yup thanks for bumping this topic, still having the problem too

bogikornel

@anthoinebThe problem still persists; when can we expect it to be resolved?

ashinobi

@Team-Storage

I am also having the same issue. Here is link on my forum post:

https://xcp-ng.org/forum/topic/12093/lost-connection-to-iso-repository/9

acomav

I have just started having this issue on one Pool yet 5 other pools are fine.
Running XOA 6.2.2.

andrewperry

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

acomav

@andrewperry I have support with XOA so will create a ticket.

stormi

@andrewperry We're preparing a release of the workaround script that our developers made.

As for the proper fix, it's actually more complex that it may seem, and developers have been working on it for a few months already. If I understood correctly, it's related to the way VDI snapshots are reverted, with responsibilities shared between the storage stack and XAPI, the fixes requiring deep changes in both stacks.

limezest

@stormi that's awesome news, thanks for the news.

Digging deeper, I found that my ISOs in my NFS ISO SR have the snapshot-of metadata field populated, and pointing to a VDI that is definitely not its parent. In fact, that parent VDI reports that it is a snapshot-of itself! Hope this helps!

Danp

@limezest said:

ISOs in my NFS ISO SR

The simplest way to correct those is to forget the VDI and then rescan the SR.

Note: The ISO names will be lost if they were uploaded via XOA, which causes them to be renamed to .IMG files.

anthoineb

Hello all,

Here we (the XCP-ng team) share a script that will help workaround the snapshot-of issue, also known as VDI not showing in XO. But first, a bit of context.

The issue

This issue has existed for quite some time, first report was late August / September 2025. Sadly, it gets more and more visible over time.

The issue is that there are 2 database fields relating to snapshot that are redundant, and the issue is that sometimes they contradict each other.

The database field that gets changed (snapshot_of), can be done so both by xapi, or SM (smapi). To fix this design issue, a new revert operation is needed but designing a new API takes time and a lot of care.

On the XAPI side, this change is implemented. The smapi part is work in progress and high on the priority list.

The script

This script only treats the symptoms of the issue and not the cause.

This script allows users to fix XAPI database records with incongruent snapshot metadata.

Changing XAPI database is always a risky operation and should be considered carefully

To operate, the script temporarily disables HA and stops XAPI to apply the changes to the database. This means that the pool is not running operations like handling backups, migrating, starting or stopping VMs, and HA is disabled during the operation.

The script needs to be run on the master host of the affected pool.

In the unlikely case the script corrupts the database, the script creates a backup before modifying the database and provides an option to restore the database from this backup.

Usage

Download the snapshot-fixer.py script here.

Check that content of the file is correct:

# sha256sum snapshot-fixer.py 
3aad01563f813571364357364f803c61cc59049fee6e8b24cfa964a03444f609  snapshot-fixer.py

snapshot-fixer.py usage:

# python3 snapshot-fixer.py -h
usage: snapshot-fixer.py [-h] {dry-run,restore-backup,rewrite} ...

Rewrite erroneous VM snapshot links.

positional arguments:
  {dry-run,restore-backup,rewrite}
    dry-run             Prints invalid values in the database, does not modify
                        any file
    restore-backup      Find a previous backup and restore it
    rewrite             Backup xapi's database, and rewrite it.

optional arguments:
  -h, --help            show this help message and exit

First run the script in dry-run mode. This will not disable the HA nor the XAPI, only print the invalid values detected that could be corrected by the script:

# python3 snapshot-fixer.py dry-run

Check the output and confirm that the VDIs are the ones you need to fix before continuing with the next steps.

The rewrite operation could take 10 seconds or more because disabling HA and XAPI are slow operations. Be patient and don't stop the script. Remember that this script should run on the master host of the affected pool.

# python3 snapshot-fixer.py rewrite
INFO:root:Check HA...
INFO:root:Shutting down xapi...
INFO:root:Regenerating database...
INFO:root:Writing database to /var/lib/xcp/state.db
INFO:root:Starting up xapi...

The last command available is restore-backup. As rewrite this command will disable HA and XAPI to operate and that could take seconds, be patient.

# python3 snapshot-fixer.py restore-backup

The next section will list error messages that could be displayed if something goes wrong.

Troubleshooting

Starting xapi timed out. Please make sure it's working by running `systemctl status xapi`

After a rewrite or restore-backup operation, the script will wait 15 seconds to re-enable the XAPI. If the timeout is reached, you will see this message asking you to re-enable it yourself.

HA was disabled and needs to be enabled back again manually. Please re-enable it by running `xe pool-ha-enable`

After a rewrite or restore-backup operation, the script will wait 30 seconds to re-enable the HA (it it was enabled before). If the timeout happens, you will see this message with the command to re-enable the HA by hand.

File '/var/lib/xcp/state.db.snapshot_of.backup' already exists, aborting. If you are sure you want to run the command again, please delete the file

This message means that the command rewrite was already run and a backup was created during the operation.

Anything else?

Don't hesitate to share your feedback on this thread to get help on this issue.

acomav

Just an update here that Vates were able to fix my pool. I assume they used the script that was just uploaded so if any one is wondering the impact, it should be fine.

limezest

@anthoineb

in fix_records at line 105

you have is_a_snapshot for one case, and is-a-snapshot for an elif.

Is the XML attribute formatted with dashes or underscores in the state.db? Or is it possible that records might exist with either format and this catches both potential cases?

(I only have underscores in my /var/lib/xcp/state.db)