Hello,

I'm a new developer on XCP-ng, I'll work on the Xen side to improve performance.
I'm a newly graduated of University of Versailles Saint-Quentin with a specialty in parallel computing and HPC, I have a big interest in operating systems.

Hello,

As some of you may know, there is currently a problem with disks with blocksize of 4KiB not being compatible to be a SR disk.
It is an error with the vhd-util utilities that is not easily fixed.
As such, we quickly developed a SMAPI driver using losetup ability to emulate another sector size to be able to workaround the problem for the moment.

The real solution will involve SMAPIv3, which the first driver is available to test: https://xcp-ng.org/blog/2024/04/19/first-smapiv3-driver-is-available-in-preview/

To go back to the LargeBlock driver, it is available in 8.3 in sm 3.0.12-12.2.

To set it up, it is as simple as creating a EXT SR with xe CLI but with type=largeblock.

xe sr-create host-uuid=<host UUID> type=largeblock name-label="LargeBlock SR" device-config:device=/dev/nvme0n1

It does not support using multiple devices because of quirks with LVM and the EXT SR driver.

It automatically creates a loop device with a sector size of 512b on top of the 4KiB device and then creates a EXT SR on top of this emulated device.

This driver is a workaround, we have automated tests but they can't catch all things.
If you have any feedbacks or problems, don't hesitate to share here

@ph7 It's only enabled for the two yum command with the --enablerepo explicitly used.
It's disabled in the config otherwise.
No need to do anything

@gb.123 Hello,
The instruction in the first post are still the way to go

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

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

@manilx Hi,

yum install plug-late-sr

Should do the trick to install it

@olivierlambert In 8.2 yes, linstor sm version is separated, it's not the case in 8.3 anymore.

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

@olivierlambert I am

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