Offline
@probain Hello,
It's likely linked to the List index out of range bug.
That bug was linked to the SR scan failing to introduce CBT_metatadata VDI in the XAPI database, could you try to launch a xe sr-scan uuid=<SR UUID> and try again to disable CBT?
If it does not work, could you share the /var/log/SMlog of around the time you are trying to disable CBT?
@Andrew Hello,
I'm also getting error on some VMs while trying to export a disk and also trying to even start some VMs from NFS (that were fine before).
Is it still a problem? It might have multiple causes. If it's still an issue, could you share the logs: /var/log/{SMlog,xensource.log,daemon.log}. It contains information that could help us investigate.
The VDI not detached cleanly means that the VDI still has a reference to the host it was running on before.
It's might be caused by the xenopsd error earlier or maybe it's the cause.
If you are sure no tapdisk are using the VDI, you can look at tap-ctl list output on each host.
You can clean this reference with the script in /opt/xensource/sm/resetvdis.py single <VDI UUID>.
@nasheayahu Sorry, I made a mistake, it's device-config:location --'
I'll edit my first post with the correct configuration, you will also likely need to give the host-uuid of the host the disk is on.
@nasheayahu Hello,
I do this in my homelab with a disk since I imported it from a physical machine:
mkdir /srv/NAS
xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=<UUID of the host with the disks>
Then you make a symlink to the device:
ln -s /dev/sda /srv/NAS/sda #although it might be better to use a stable identifier if you have multiple disks
xe sr-scan uuid=<UUID of the udev SR>
The disk will appear as a VDI in the SR that you can then plug to a VM.
I also renamed the VDI [NOSNAP][NOBAK] NAS Drive
[NOSNAP][NOBAK] instruct XO to not snapshot and export the disk in backups (since it can't).
It's not passthrough, as in the disk is not directly given to the VM, but tapdisk (the process virtualizing storage) will give access to the whole disk to the guest, so it can mount any FS on it.
The udevSR is usually used for plugging USB from what I could gather from existing code. But users in homelabs have been using it like this for a while.
Though you will likely not have native performance level since it's not exactly passthrough.
Hello again,
The updates have been made available and RPU with xostor should be safe to run 
https://xcp-ng.org/blog/2026/05/07/may-2026-updates-2-for-xcp-ng-8-3-lts/
@ccooke Hello,
We have a fix, we are aiming to validate it rapidly so it shouldn't happen for others.
Thank you for reporting the issue. I'll update the thread again when the update is available and it should be safe for other people going through here to update using the RPU.
@ccooke Hello,
You should be able to make the XOSTOR SR work again if you update sm and sm-fairlock on the other hosts.
yum update sm sm-fairlock
Then you should be able to re-plug the SR on the master and proceed with the RPU.
@IgorGlock Hello,
Could you share the exception that should be in /var/log/SMlog?
@Andrew Hello,
I have been able to find the problem and make a fix, it's in the process of being packaged.
I can confirm it only happen for file based SR when using purge snapshots.
For some reason, the vdi type of CBT_metadata is cbtlog for FileSR but stays the image format it was for LVMSR
And it would make a condition fail during the list_changed_blocks call.
@Andrew Hello Andrew,
Thank you for reporting.
It appear that the CBT on FileSR-based SR is not working in addition to data-destroy (the option that allow to remove the VDI content and only keep the CBT).
Can you confirm that you are using a FileSR (ext or nfs)?
Is it possible to disable purge data on the CR job?
@acebmxer Hello,
The error VDI_CBT_ENABLED means that the XAPI doesn't want to move the VDI to not break the CBT chain.
You can disable the CBT on the VDI before migrating the VDI but if you have snapshots with CBT enabled it can be complicated and it might necessitate to remove them before moving the VDI.
We have changes planned to improve the CBT handling in this kind of case.
@ovicz Hello,
From what I saw in your logs, you have a non QCOW2 sm version, it made the QCOW2 VDIs not available to the storage stack and the XAPI lost them.
If you update again while enabling the QCOW2 repo:
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-qcow2
A SR scan will make the VDI available to the XAPI. Though you will have to identify them and connect them to the VM manually, since this information was lost.
@nuentes Hello,
Following an IA seem to be dangerous already, no need for Skynet 
There is a documentation part about regenerating the initrd: https://docs.xcp-ng.org/troubleshooting/common-problems/#initrd-is-missing-after-an-update
You can likely used what you did above to mount the XCP-ng FS and then regenerate the initrd using this command.
It's not an initramfs that you need to generate but a initrd
@cmanos No problem, glad I could helped.
As Olivier also pointed above, it's not an issue anymore when using QCOW2 which is currently in beta, so hopefully it's only a short workaround
@cmanos Hello, there is a problem with VHD on 4KiB block size devices, you can use the largeblock SR to workaround the issue:
https://xcp-ng.org/forum/topic/8901/largeblocksr-for-4kib-blocksize-disks
@olivierlambert In 8.2 yes, linstor sm version is separated, it's not the case in 8.3 anymore.
@Razor_648 While I was writing my previous message, I have been reminded that there are also issues with LVHDoISCSI SR and CBT, you should disable CBT on your backup job and on all VDI on the SR. It might help with the issue.
@Razor_648 Hi,
The log you showed only mean that it couldn't compare two VDI together using their CBT.
It sometimes happen that a CBT chain become disconnected.
Disabling leaf-coalesce mean it won't run on leaf, VHD chain will always be 2 depths deep.
You migrated 200 VMs, every disks of those VMs had snapshot made that then need to be coalesced, it can take a while.
Your backup then also do a snapshot each time while running that need to be coalesced.
There are GC in both version of XCP-ng 8.2 and 8.3.
The GC is run independently of auto-scan, if you really want to disable it you can do it temporarily using /opt/xensource/sm/cleanup.py -x -u <SR UUID> it will stop the GC until you press enter. I guess you could run it in a tmux to make it stop until next reboot. But it would be better to find the problem or if there really is no problem let the GC work until it's finished.
It's a bit weird to need 15 minutes to take a snapshot, it would point to a problem though.
Do you have any other error than the CBT one in your SMlog?