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

Dave Allan dallan at redhat.com
Mon Oct 26 21:27:09 UTC 2009


Shyam_Iyer at Dell.com wrote:
>>>> 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.
>>>>
>>> Sorry. I wasn't clear.
>>>
>>> The present design allows the following -
>> Hi Shyam,
>>
>> Your ASCII diagram got mangled by the emailing process.  Would you
> mind
>> sending a text document with it?  I think I see what you're saying,
> but
>> I'd like to confirm with your diagram before I comment further.
>>
>> Dave
> 
> Dave- Attached diagram doc describes the use cases.
> 
> Thanks
> -Shyam
> 

Ok, you're proposing what I thought you were proposing.  My objection to 
what you want to do is that I think this sort of complexity is better 
done in the client application than in libvirt.  In other words, I think 
that *some code*, *somewhere* is going to have to loop through all the 
sessions and create and delete each one and enumerate the LUs on each 
session.  I think we are only debating whether that loop should be in 
the client application or in libvirt.  Why do you think we should put 
that complexity into libvirt?

The way I see a client using the API is:

1) The client application enumerates the initiator IQNs it wants to use 
to establish sessions
2) The client application enumerates the target IQNs it wants to use to 
establish sessions
3) For each session:
	a) The client constructs the XML describing the session and
	b) calls create pool

The way you see the client using the API is:

1) The client application enumerates the initiator IQNs it wants to use 
to establish sessions
2) The client application enumerates the target IQNs it wants to use to 
establish sessions
3) The client constructs the XML describing all the sessions and
4) calls create pool

Is there a functional difference?

Dave




More information about the libvir-list mailing list