Re: [libvirt] [libivrt] storage: Two iSCSI node records may cause refreshing iscsi pool failed

On 12/01/2016 10:58 PM, Shichangkuo wrote: Apologies for languishing on list for a while - I've been concentrating on other areas of the code and didn't have the capacity to context switch to iSCSI details... Anyway - first off - please train your composition window to wrap the line length, the above is difficult to read with line wrapping. Second, please read details from commit id 'ae65c908b' - there was a reason and bugzilla for going from using/parsing output of a: iscsiadm --mode discovery --type sendtargets --portal portal --op nonpersistent to iscsiadm --mode node --portal portal --targetname target --op new I also suggest you follow the commit referenced (e.g. commit id '5605790') from the above change as well as the original commit id '3c12b654' to understand the "history" of this code. While trying to parse through the above it's really not clear to me what the order of operations is. In particular what is meant by the paragraph that starts "When we already executed...". It seems you are indicating you have something else managing session logins and it was run prior to libvirt pool startup. IOW: session [2] is/was started by what and session[3] is/was started by what? If you could show the step by step processing and the resulting /dev/sdX that is causing the issue - it would help a lot. Finally, your suggestion is to change Start to: iscsiadm --mode discovery --type sendtargets --portal portal --op new would seem to be closer to the original design which was changed by commit id 'ae65c908b' w/ the difference being usage of --op new rather than --op nonpersistent. I didn't refresh my short term memory on the difference between new and nonpersistent... Perhaps what's necessary is a way to "alter" Start to use "either" method depending on some pool configuration option. See commit '5d8c31c' - it uses the NodeNew methodology rather than the ScanTargets methodology. If the two cannot co-exist (which is what I think you're claiming), then the storage pool <source> XML <device> element could get a new attribute such as "mode" which could either be "node" or "discovery" (defaulting to "node") that would cause the Start code to use the NodeNew or ScanTargets algorithm based on setting of the pool source device attribute. If this "solves" your issue, then just propose a patch to do this. At the very least please help me with understanding the problem. Tks - John