[Pkg-xen-devel] Bug#1106420: xen-utils-common: block-iscsi script doesn't work when iqn is a prefix of an existing iqn

[Hans van Kranenburg]

Hi Tim!



Thanks for the report.

I see the problem, and the changes make sense indeed.

On 5/24/25 6:33 PM, Tim Woodall wrote:
> Package: xen-utils-common
> Version: 4.17.5+23-ga4e5191dc0-1+deb12u1
> Severity: normal
> 
> two issues with block-iscsi
> 
> 1. If the iqn that is being used as a disk device is a prefix of an 
> existing in use iqn then xl create will fail with
> libxl: error: libxl_device.c:1337:device_hotplug_child_death_cb: script: Device already opened
> 
> My fix is to match a space before and after the iqn.
> 
> iscsiadm -m session | grep ' iqn.xen17:trixie17 '
> tcp: [32] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1 iqn.xen17:trixie17 (non-flash)
> 
> Without the trailing space:
> iscsiadm -m session | grep 'iqn.xen17:trixie17'
> tcp: [30] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1 iqn.xen17:trixie17-build (non-flash)
> tcp: [32] [fd01:8b0:bfcd:100:230:18ff:fe08:5ad6]:3260,1 iqn.xen17:trixie17 (non-flash)
> 
> 2. There's no way to specify the LUN, it seems to always want lun-0. All 
> of my LUNS are 1, so I've changed the default to 1 rather than 0 but it 
> needs an extra lun=<> parameter.
> 
> diff -u scripts/block-iscsi.distrib scripts/block-iscsi
> --- scripts/block-iscsi.distrib 2022-12-29 23:12:25.000000000 +0000
> +++ scripts/block-iscsi 2025-05-24 16:24:53.000000000 +0000
> @@ -26,6 +26,8 @@
>  dir=$(dirname "$0")
>  . "$dir/block-common.sh"
>  
> +LUN=1
> +
>  remove_label()
>  {
> [...]
If we want to see these changes in our Debian Xen packages, then they
should first be sent to upstream Xen and be accepted and included there.

If you would like to do this, we can help with some advice and guidance.

Meanwhile, I actually have a another suggestion.

In this case, when using iSCSI, I would recommend using multipath, even
when there is just 1 path to the lun.

A few reasons for this are:

1. You can use a feature in multipath where all IO is queued in case
there are 0 paths available to the target.
(features='1 queue_if_no_path')

>From the perspective of the user of the block device (in this case your
Xen domU), this looks just like it hangs and is super slow, but there
will be no hard IO errors causing problems in the VM.

This means you can 'just' unplug network cables or accidentally offline
your lun and online it again, and stuff will hang and will continue
after the communication to the iSCSI target is restored.

Stuff like disappearing and reappearing block devices (while being
attached to a Xen domU) is something that really quickly brings you into
unknown edge case horror territories where bad things might happen.

2. You have a stable device name /dev/mapper/<wwid> which you can use
just with the 'normal/regular' block script.

disk = [
    "/dev/mapper/<wwid>,raw,xvda,rw",
]

It's fun that there is a block-iscsi variant, but while trying to make
fixes I suspect you also feel a bit uncomfortable because of how fragile
the code is, yolo matching strings in a shell script... This block-iscsi
was added in 2013, and there is 1 small fix done to it in 2016, and I
have no idea how much it is used.

---- >8 ----

At work, in the past, I used all of this a lot. We had NetApp storage
and then a whole bunch of Xen dom0 with multipath which would combine
several iSCSI network paths into multipath block devices, on which we
put LVM again (with sanlock and live migration), and then the actual LVs
were the block devices for Xen domUs. And it actually worked really well.

There's a bunch of knobs and handles in the iscsi and multipath config
to get this right. If you're interested in some been-there-done-that, I
would not mind sharing something.


Thanks,
Hans