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

Dave Allan dallan at redhat.com
Thu Oct 22 21:24:56 UTC 2009


Shyam_Iyer at 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.

> In this case the user knows that Pool A and Pool B are the same set of
> LUNs and it is a deliberate result.
> 
> Possible usecase - Live Migration scenarios ...
> 
> Increasing the initiator IQNs can be more effective in Load balancing,
> fault tolerance scenarios and the choice of the pools can be easily
> identified using Target IQNs.

If you can search for one pool with a particular target IQN, you can 
search for multiple pools with that IQN, right?

> Also, with the above design if there is a need to create separate pools
> out of the same set of LUNs behind a Target IQN then that can be done
> explicitly by creating a fresh XML conf for each initiator IQN.




More information about the libvir-list mailing list