Re: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)

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

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.