On 07/03/2018 01:08 AM, Michal Prívozník wrote: > On 07/03/2018 01:38 AM, John Ferlan wrote: >> >> >> On 06/29/2018 11:01 AM, Michal Privoznik wrote: >>> When scanning for targets, iSCSI might give different results >>> depending on the interface used. This is basically just name of >> >> assuming this means whether the initiatoriqn interface was used > > Yes. > >> >>> config file under /etc/iscsi/ifaces to use. The file contains >>> initiator IQN thus different results claim. >>> >> >> Strange to have activity here - was there a bz? Or something found by >> the (I assume) GSoC project: >> >> https://www.redhat.com/archives/libvir-list/2018-June/msg00249.html >> >> Touching something that's been avoided for 8 years is always scary, but >> if it's broken, then sure it ought to be fixed. > > There is no BZ. And yes, the GSoC project got me experimenting (because > for libiscsi backend we will have to make IQN required since libiscsi > does not parse anything from /etc/iscsi nor initiatorname.iscsi). And > while experimenting I've tired to put my own IQN into iscsi pool we > already have and found this bug. > FWIW: To a degree this is restoring the initiatoriqn argument that commit 027986f5 removed... [...] >>> +static int >>> +virISCSIScanTargetsInternal(const char *portal, >>> + const char *ifacename, >>> + size_t *ntargetsret, >>> + char ***targetsret); >>> + >>> + >>> struct virISCSISessionData { >>> char *session; >>> const char *devpath; >>> @@ -286,9 +293,10 @@ virISCSIConnection(const char *portal, >>> * iscsiadm doesn't let you send commands to the Interface IQN, >>> * unless you've first issued a 'sendtargets' command to the >>> * portal. Without the sendtargets all that is received is a >>> - * "iscsiadm: No records found" >>> + * "iscsiadm: No records found". However, we must ensure that >>> + * the command is issued over interface name we invented above. >> >> "invented" - again is this the make sure it's issued over the >> initiatoriqn interface? > > Yes. And we construct the interface name at the beginning of this function. > Oh right, the virStorageBackendCreateIfaceIQN call which creates that libvirt-iface-* name. That's just one of those context things that you know when you've been working through the code ;-). Still without the next patch, does this work? John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
