VDI not showing in XO 5 from Source.

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)

acomav

I spoke too soon. The issue has returned the following day which means it is most likely the nightly backups triggering the issue.

anthoineb

@limezest You're right, we'll fix this.

With this typo, the elif branch will always be false and not executed, it's dead code. As it is a less common issue than the first branch of the if, the script will left behind this particular case but will still fix the majority of snapshot_of problems.
The script can still be used safely.

andrewperry

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

Danp

@andrewperry This script hasn't been designed or tested to work on XCP-ng 8.2.1 because it reached EOL status last year. Installing Python3 on XCP-ng 8.2.1 should be fine, but we aren't able to guarantee the script's functionality on that platform.

Upgrading to XCP-ng 8.3 is your best option here so that you can benefit from product improvements, security updates, etc.

andrewperry

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

andrewperry

@danp I see your response to my concern was to add a block on the script being able to run on 8.2, without an update to the elif bug @anthoineb acknowledged. While I can remove your addition and fix that other bug myself, I just wanted to give you some feedback as to why I expressed the issue in the way I did - it wasn't because I feel an entitlement to anything, just sharing my perceptions to @antoineb

I have been a xen cli user for a couple of decades, give or take. I moved to xcp-ng with a lot of PV legacy. That was a blocker to using 8.3 straight away, otherwise I would have. The workflow I had established to update the VMs to HVM included adding a new volume for /boot and /boot/efi, and then switching boot OFF on the legacy disk. It was worrying when I went to complete the migration to HVM with the announced EOL of 8.2.1, that suddenly the disks I needed to work with, both legacy and new, had disappeared in XO so I couldn't follow my SOP to move the VMs to HVM, and then proceed to upgrade to 8.3.

Given how relatively widespread this issue seems to be, I am surprised that Vates wouldn't treat it as a reputational issue and want to help users to resolve it so that corporates can have confidence to move their cloud to xcp-ng platform, even if they are a startup or in the initial stages of a move and can't yet invest in Pro Support. I note you have a "Pro Support Team" badge, and understand that may not mean you work for Vates, but I gather offer Pro Support. Valuable service.

While I am not encouraging this thread to become a marketing channel, it would speak well for xcp-ng, Vates and the Pro Support community if this important issue was handled differently - even if it was "we have tested on 8.2.1 internally and should be able to fix it for you quickly and cost effectively if you join our X plan or request a quote on Y page."

I appreciate all you've shared and wasn't being dismissive of your recommendation to upgrade to 8.3, just the timing of this issue - arising right before the EOL of 8.2.1 made that a bit of a "chicken and egg problem".

I gather from what you've said on this thread that you don't expect upgrading to 8.3 to be a problem with VDI in this state, so I guess I will just soldier on with creating an xcp-ng CLI SOP to upgrade the remaining PVs to HVM, upgrade to 8.3, and then use the script that has been shared - since you've now made it clear in the code that it shouldn't be run on 8.2.

I am thankful that it was shared as guidance, if not a fix in my situation.

andrewperry

Just wanting to express my thanks for the script which seemed to do the trick in resolving this issue for us, once we were able to get the HVM migrations completed to enable the move to 8.3.

We understand it is not a long term fix for the underlying issue, but appreciate all we have been given. Thanks.

limezest

It's a been a while since this thread has been updated, so I figure I should share what I've learned.

First: here's a script which reproduces the bug reliably and includes steps to revert: https://gist.github.com/dmeiselman/ecb35ffcb675c38e6eeb14292948c2e3
Don't run this on your production cluster.

Here's my understanding of this bug and it's current state:

Some operation sets the snapshot_of metadata field of a valid snapshot to NULL (We can do this intentionally by making a VM, taking a snapshot of it, then deleting the parent disk.)
If you perform a revert of this invalid snapshot, revert's "Updating the snapshot_of fields" step looks for VDIs whose snapshot_of matches the snapshot's source disk, so it can relink them to the new disk. If the source is NULL, the search becomes "every VDI with NULL", which matches ISOs, base images, ordinary VM disks. Congrats, every real disk and ISO in every SR now looks like a snapshot.
Now these disks have a value set for snapshot_of which means XOA hides the VDI in the web UI.

The fix is to delete or clone the super-parent, and all of its snapshots. sr_scan will correct the metadata for all the VMs and ISOs and you're back where you started.

This happens in line 401 of https://github.com/xapi-project/xen-api/blob/v26.1.19/ocaml/xapi/xapi_vm_snapshot.ml#L389-L408

PR 7290 https://github.com/xapi-project/xen-api/pull/7290 has a fix, which looks like it's coming in xapi v26.1.21. (It's worth reading the Pull Request, as it has a more graceful description of the issue, it really helped me wrap my head around it.)