I am trying to understand whether I am hitting a bug, a known limitation, or a configuration issue when using a large QCOW2 VDI on an LVM SR.

Environment

I have an existing VM with several virtual disks.

Most of the data disks are approximately 2 TiB and were created as VHD VDIs. They have been working correctly for a long time.

Example:

virtual-size: ~2 TiB
image-format: vhd
vdi_type: vhd

Inside the guest, several of these disks are combined using LVM to provide a larger filesystem.

The Xen Orchestra instance is built directly from source and kept up to date from the upstream source tree.

The storage repository involved is an existing local LVM SR that has been in production for several years. It was not newly created for this test and has been used successfully with VHD VDIs over that period.

I now need to add significantly more storage and would prefer to avoid continuing to add multiple ~2 TiB VHD disks.

I therefore created a new 15 TiB virtual disk using the current Xen Orchestra build.

The disk was automatically created as QCOW2:

virtual-size: 16492674416640
image-format: qcow2
vdi_type: qcow2
Storage Repository

The VDI is stored on the existing local LVM SR.

The SR has approximately:

Total size: ~44 TiB
Free after creating the new VDI: ~4 TiB

There was sufficient free space before creating the new 15 TiB VDI.

At the LVM level, the QCOW2 LV is present and has the expected size:

QCOW2-<uuid> ~15.00 TiB
Problem

When the 15 TiB QCOW2 disk is attached to the VM, the VM fails to start.

Xen Orchestra reports:

SR_BACKEND_FAILURE_46

The VDI is not available
[opterr=['XENAPI_PLUGIN_FAILURE',
'make_chain_rw',
'CommandException',
'Input/output error']]

The same VM starts normally when this QCOW2 VDI is removed or detached.

All the existing VHD disks on the same SR continue to work normally.

Relevant SMlog output

The Storage Manager detects the QCOW2 LV and can query its size.

For example:

blockdev --getsize64 /dev/<VG>/QCOW2-<uuid>

succeeds.

It also executes:

qemu-img measure \
-O qcow2 \
--output json \
-o cluster_size=65536 \
--size 16492674416640

successfully.

The failure happens during VDI activation:

BLKTAP2:<function VDI._activate_locked ...>:
EXCEPTION <class 'XenAPI.Failure'>,

['XENAPI_PLUGIN_FAILURE',
'make_chain_rw',
'CommandException',
'Input/output error']

self._make_chain_rw()

File "/opt/xensource/sm/LVMSR.py", line ..., in _make_chain_rw
raise Failure(result['ErrorDescription'])
Current VM disk layout

Simplified layout:

System disk VHD
Home disk VHD

~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD

15 TiB QCOW2 <-- new disk causing the failure

The existing VHD disks work correctly.

The problem only appeared after adding the large QCOW2 VDI.

Questions

Is a 15 TiB QCOW2 VDI on an existing local LVM SR expected to work reliably on current XCP-ng 8.3?

Is mixing VHD and QCOW2 VDIs on the same VM and on the same SR fully supported?

Could the fact that this is an older LVM SR created several years ago make any difference with the newer QCOW2 support?

Does the following error correspond to any known QCOW2/LVM issue?

make_chain_rw
CommandException
Input/output error

Are there specific minimum versions of xapi, sm, blktap, or other storage components required for large QCOW2 VDIs?

Would a different SR type be recommended for VDIs of this size, or should this configuration work normally?

The Xen Orchestra instance is built from source and kept current, so I am mainly trying to determine whether the issue is on the XCP-ng/storage side rather than the XO side.

I can provide additional anonymized SMlog, package versions, qemu-img output and LVM diagnostics if required.

Thanks.