[pve-devel] iscsi and multipathing

[Mira Limbeck]

Hi Timo,

At the moment I'm working on storage mapping support for iSCSI.
This would allow one to configure different portals on each of the hosts
that are logically the same storage.

If you tried setting up a storage via iSCSI where each host can only
access a part of the portals which are announced, you probably noticed
some higher pvestatd update times.
The storage mapping implementation will alleviate those issues.

Other than that I'm not aware of anyone working on iSCSI improvements at
the moment.
We do have some open enhancement requests in our bug tracker [0]. One of
which is yours [1].

Regarding multipath handling via the GUI there hasn't been much of a
discussion on how we could tackle that yet. It is quite easy to set up
[2] the usual way.


Sorry, I might have missed your bug report previously, so I'll go into a
bit more detail here. (I'll add that information to the enhancement
request as well)

> When adding iscsi storage to the data center there could possiblity to
> do a iscsi discovery multiple times against different portal ips and
> thus get multiple path to a iscsi san.

That's already the default. For each target we run the discovery on at
least one portal since it should announce all other portals. We haven't
encountered a setup where that is not the case.

> multipathd should be updated with the path to the luns. The user
> would/could only need to have to add vendor specific device configs
> like alua or multibus settings.

For now that has to be done manually. There exists a multipath.conf
setting that automatically creates a multipath mapping for devices that
have at least 2 paths available: `find_multipaths yes` [3].

> Then when adding a certain disk to a vm, it would be good if it's wwn
> would be displayed instead of the "CH 00 ID0 LUN0" e.g. So it would be
> easier to identify the right one.

That would be a nice addition. And shouldn't be too hard to extract that
information in the ISCSIPlugin and provide it as additional information
via the API.
That information could also be listed in the `VM Disks` page of iSCSI
storages.
Would you like to tackle that?

> Also when changing lun size would have been grown on the storage side,
> it would be handy to have a button in pve web gui to "refresh" the
> disk in the vm. The new size should be reflected in the hardware
> details of the vm. And the qemu prozess should be informed of the new
> disk size so the vm would not have to be shutdown and restarted.

Based on experience, I doubt it would be that easy. Refreshing of the
LUN sizes involves the SAN, the client, multipath and QEMU. There's
always at least one place where it doesn't update even with
`rescan-scsi-bus.sh`, `multipath -r`, etc.
If you have a reliable way to make all sides agree on the new size,
please let us know.



[0]
https://bugzilla.proxmox.com/buglist.cgi?bug_severity=enhancement&list_id=50969&resolution=---&short_desc=iscsi&short_desc_type=allwordssubstr
[1] https://bugzilla.proxmox.com/show_bug.cgi?id=6133
[2] https://pve.proxmox.com/wiki/Multipath
[3]
https://manpages.debian.org/bookworm/multipath-tools/multipath.conf.5.en.html