Shyam_Iyer@Dell.com wrote:
I like the functionality. To restate what I said when you first proposed it, though, each pool is currently based on one iSCSI session, so to preserve that paradigm, you should only allow zero or one initiator IQNs per pool. If the pool contains an initiator IQN, it will be used when creating the session. If it does not contain an initiator IQN, the system default initiator IQN will be used. If you require multiple initiator IQNs, you create multiple pools, one per initiator IQN each with the same target. I think that approach will result in a very small patch. Do you have a specific use case for which that approach would not work?
Dave
Yes.
Let us say I want to consider the LUNs behind a Target IQN as
Shyam_Iyer@Dell.com wrote: pool
A.(Target centric terminology)
If each initiator iqn creates separate pools than there will be duplicity of the same set of LUNs. And this is a side effect not necessarily a deliberate one. I'm not sure I understood you. If a LUN is visible on multiple sessions, there's going to be duplication of LUNs regardless of whether you use one pool with multiple sessions or multiple pools with one session per pool, because you're still establishing those sessions. You're also not guaranteed to have the same set of LUNs on both sessions, so you can't trust that the set of LUNs you get on one session is the same as the set on another session.
Sorry. I wasn't clear.
The present design allows the following - Hi Shyam,
Your ASCII diagram got mangled by the emailing process. Would you mind sending a text document with it? I think I see what you're saying, but I'd like to confirm with your diagram before I comment further.
Dave
Dave- Attached diagram doc describes the use cases.
Thanks -Shyam
Ok, you're proposing what I thought you were proposing. My objection to what you want to do is that I think this sort of complexity is better done in the client application than in libvirt. In other words, I think that *some code*, *somewhere* is going to have to loop through all the sessions and create and delete each one and enumerate the LUs on each session. I think we are only debating whether that loop should be in the client application or in libvirt. Why do you think we should put that complexity into libvirt? The way I see a client using the API is: 1) The client application enumerates the initiator IQNs it wants to use to establish sessions 2) The client application enumerates the target IQNs it wants to use to establish sessions 3) For each session: a) The client constructs the XML describing the session and b) calls create pool The way you see the client using the API is: 1) The client application enumerates the initiator IQNs it wants to use to establish sessions 2) The client application enumerates the target IQNs it wants to use to establish sessions 3) The client constructs the XML describing all the sessions and 4) calls create pool Is there a functional difference? Dave