[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Shyam_Iyer 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
so to preserve that paradigm, you should only allow zero or one
initiator IQNs per pool.  If the pool contains an initiator IQN, it
be used when creating the session.  If it does not contain an
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?


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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]