On 12/01/2016 10:58 PM, Shichangkuo wrote: > Hi, John > When starting an iscsi storage pool, libvirt will execute “iscsiadm --mode node --portal 192.168.0.42 --targetname iqn.2003-10.com.xxxx --op new”, which is called by virISCSINodeNew. > This will add an iSCSI node record. The record file is /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260. > > When we already executed "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new", another iSCSI node record will be produced in /etc/iscsi/nodes/iqn.2003-10.com.xxxx/192.168.0.42,3260,1/default. > Then two iscsi sessions, as [2] and [3], will be logged in when we start the pool. > > Device of session [2] is /dev/sde, and device of session [3] is /dev/sdf. > But there is only one path in /dev/disk/by-path, let's assume it is /dev/sdf. > > Refreshing storage pool will choose first session, like [2], and libvirt will find sde NOT sdf in /dev/disk/by-path. We will not find sde, then no volumes is found in the pool. > I think the root reason is we have two iSCSI node records. > Can we use "iscsiadm --mode discovery --type sendtargets --portal 192.168.0.42 --op new" in virISCSINodeNew? > 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 > diff --git a/src/util/viriscsi.c b/src/util/viriscsi.c > index 504ffbd..a8a8644 100644 > --- a/src/util/viriscsi.c > +++ b/src/util/viriscsi.c > @@ -469,9 +469,9 @@ virISCSINodeNew(const char *portal, > int ret = -1; > > cmd = virCommandNewArgList(ISCSIADM, > - "--mode", "node", > + "--mode", "discovery", > + "--type", "sendtargets", > "--portal", portal, > - "--targetname", target, > "--op", "new", > NULL); > > Thanks, > Changkuo. > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from H3C, which is > intended only for the person or entity whose address is listed above. Any use of the > information contained herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
