>> 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