9:58 p.m.
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?
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!
9:08 a.m.
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!
2881
days inactive
2915
days old
1 comments
2 participants
participants (2)
-
John Ferlan -
Shichangkuo