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

[Dave Allan]

Shyam_Iyer at Dell.com wrote:
>> -----Original Message-----
>> From: Dave Allan [mailto:dallan at redhat.com]
>> Sent: Friday, October 23, 2009 2:55 AM
>> To: Iyer, Shyam
>> Cc: libvir-list at redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
>> Subject: Re: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)
>>
>> Shyam_Iyer at 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


> 
> 1)
> ----------LUN A
> 	
> |
> 		---------Initiator IQN1----Session
> 1--------------<Target IQN A>------------------LUN B
> 		|
> 		|
> ----------LUN A
> 		|
> |
> Pool A---------------Initiator IQN2----Session 2--------------<Target
> IQN A>------------------LUN B
> 		|
> 		|
> 		---------Initiator IQN3----Session
> 3--------------<Target IQN B>------------------LUN C
> 
> 		Target IQN A, B and C 
> 
> 
> 		Or, 
> 	
> ----------LUN A
> 2)
> |
> 		---------Initiator IQN1----Session
> 1--------------<Target IQN A>------------------LUN B
> 		|
> 		|
> ----------LUN C
> 		|
> |
> Pool A---------------Initiator IQN2----Session 2--------------<Target
> IQN B>------------------LUN D
> 		|
> 		|
> 		---------Initiator IQN3----Session
> 3--------------<Target IQN C>------------------LUN E
> 
> 
> 
> And also, the one that you are describing. One pool for each initiator
> IQN
> 
> 3)
> 		------------------------------------
> ----------LUN A
> 		|
> |
> Pool A----------------Initiator IQN1---Session 1--------------<Target
> IQN A>------------------LUN B      
> 		|
> |
> 		------------------------------------
> ----------LUN C
> 
> Today, the pool concept abstracts multiple LUNs behind a Target IQN into
> a common storage pool with a single session. The advantage of doing that
> with one pool is that managing the multiple LUNs with one pool becomes
> easy.
> 
> By also abstracting multiple initiator iqns into a pool concept, the
> management of storage pools becomes easy for the same reason - "LUN
> management".
> At the same time it allows flexibility to realize a one pool per
> initiator iqn scenario that exists today.
> 
> Consider the following example.
> 
> 
> If we use a separate pool for each initiator IQNs.
> #virsh
> <virsh> pool create <StorageArray_1_initiatoriqn1>
> <virsh> pool create <StorageArray_1_initiatoriqn2>
> ...........................................
> ...........................................
> <virsh> pool create <StorageArray_1_initiatoriqnN>
> 
> If all pools associated with StorageArray_1 had to be destroyed then the
> following would happen.
> <virsh> pool destroy <StorageArray_1_initiatoriqn1>
> <virsh> pool destroy <StorageArray_1_initiatoriqn2>
> ...........................................
> ...........................................
> <virsh> pool destroy <StorageArray_1_initiatoriqnN>
> 
> 
> In the design that allows multiple initiator IQNs for a pool.
> #virsh
> <virsh> pool create <StorageArray_1>
> In this design the XML contains Multiple initiator IQNs and multiple
> sessions can be established for the pool "StorageArray_1".
> <virsh> pool destroy <StorageArray_1>
> With this design all the sessions for this pool will get destroyed with
> one effort.
> 
>