Team - Storage group | XCP-ng and XO forum

dthenot

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/

dthenot

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

dthenot

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

dthenot

@IgorGlock Hello,

Could you share the exception that should be in /var/log/SMlog?

dthenot

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

dthenot

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

dthenot

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

dthenot

@rzr Host updated

Team - Storage

Posts

Member List