Shyam_Iyer@xxxxxxxx wrote:
Shyam_Iyer@xxxxxxxx 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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list