RE: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)
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.