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

[Shyam_Iyer at Dell.com]

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

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.