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.
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.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list