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