[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)



Shyam_Iyer Dell com wrote:
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
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]