> >> 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 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list