> -----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 - 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