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

[Shyam_Iyer at Dell.com]

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

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.

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.