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