FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> writes: > you don't need to tell all the targets to an initiator. Do you really > want one initiator to see 70 targets? It's unlikely. You can use the > ACL list to configure targets exported to an initiator. I maintain the code behind a cloud infrastructure provider. The guest operating systems move around a cluster of machines dynamically to balance load, and each of them will typically access two or three drives over iSCSI. Consequently, at the target end I don't know which devices will be needed by which hosts, and this will change continuously at run time with one host logging out as a guest leaves it and another logging in as that guest joins. I fixed this tgtd segfault because I was continuously seeing it, not because it was something that I might theoretically hit on rare occasions! Of course, I could implement my own out-of-band pre-login and post-logout mechanisms to add/remove an initiator to/from a target's ACL immediately before doing a discovery/after logging out, but stuff like this really shouldn't be necessary and I'd rather just hack away the limit in tgtd given this doesn't break anything. > In addition, discovery Session is not a must (you can configure > targets on the initiator box by hand). I do know the target name, host name and port exactly at the initiator. If it's possible to use OpenISCSI to log in to the target using just these details and completely skip the discovery step, or to request discovery of a specific target, that would solve the problem for me, but as far as I can see, one can't do iscsiadm -m node -T "$TARGET" -p "$HOST" -l unless one has previously run iscsiadm -m discovery -t sendtargets -p "$HOST" even though all the required info is already provided to the login command! Similarly, iscsiadm -m discovery -t sendtargets -p "$HOST" -T "$TARGET" isn't supported. (Does the sendtargets protocol even allow it?) Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |