> >> shyam_i...@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
The attached patch design allows the following combinations
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 is possible today. 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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
