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