+++ This bug was initially created as a clone of Bug #1118305 +++ Original description of problem (against libguestfs): libguestfs has no means to set an explicit initiator IQN for iSCSI connections. A default intiator IQN ( incase of LIBGUESTFS-BACKEND=direct ) or a random IQN ( in case of libvirt backend ) is used for iSCSI connections. This creates problems when storage systems expect a preconfigured initiator IQN to be used while establishing iSCSI connections. The underlying QEMU command has an option (`-iscsi initiator-name=<initiator-iqn>' to set initiator IQN string explicitly. But currently libguestfs has no option to set this parameter and pass it on to QEMU. ------ To implement this fully, we will also need support in libvirt. I posted a message to libvir-list which contains fuller details: https://www.redhat.com/archives/libvir-list/2014-July/thread.html#00281
Since this is a global setting and not a per-disk setting, figuring out what the XML would look like is a bit tricky since we probably need a new top level element like <domain> <iscsi XXX/> </domain> or similar
Theoretically qemu allows to set per-drive iscsi properties, although the system for this does not work for IQNs containing colons: http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg06501.html http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00025.html (continuation of the above) I'm currently playing with qemu's -drive to allow settings better per-drive iscsi properties.
(In reply to Pino Toscano from comment #2) > Theoretically qemu allows to set per-drive iscsi properties, although the > system for this does not work for IQNs containing colons: > http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg06501.html > http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00025.html > (continuation of the above) > > I'm currently playing with qemu's -drive to allow settings better per-drive > iscsi properties. Can't you use a json: URL to specify an IQN with a colon in it? Search the qemu man page for "json:" for examples.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.