Re: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)
Shyam_Iyer(a)Dell.com wrote:
>>> Shyam_Iyer(a)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