[libvirt] [RFC] Multi-IQN proposal

[Shyam_Iyer at Dell.com]

Thanks for the review.

> -----Original Message-----
> From: Dave Allan [mailto:dallan at redhat.com]
> Sent: Saturday, September 26, 2009 2:43 AM
> To: Iyer, Shyam
> Cc: libvir-list at redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
> 
> Shyam_Iyer at Dell.com wrote:
> > Would this proposal be acceptable ?
> 
> In principle, I think what you're proposing is reasonable, and is
> certainly contemplated by the iSCSI specs.
> 
> > Example XML schema for an iSCSI storage pool created --
> >
> >  <pool type="iscsi">
> >   <name>dell</name>
> >   <uuid>cf354733-b01b-8870-2040-94888640e24d</uuid>
> >   <capacity>0</capacity>
> >   <allocation>0</allocation>
> >   <available>0</available>
> > - <source>
> >   <initiator iqnname = "<initiator IQN1>">
> >   <initiator iqnname = "<initiator IQN2>">
> >   ........................................
> >   ........................................
> >   <host name="<iSCSI target hostname or Target IP address>" />
> >   <device path="<iSCSI Target IQN name>" />
> >   </source>
> > - <target>
> >   <path>/dev/disk/by-path</path>
> > - <permissions>
> >   <mode>0700</mode>
> >   <owner>0</owner>
> >   <group>0</group>
> >   </permissions>
> >   </target>
> >   </pool>
> 
> I think you have the initiator name specified in the right place in
the
> XML.  I would make the initiator iqn an element rather than an
> attribute, since your proposal contemplates adding additional
initiator
> specific information later, and stylistically I think elements will be
> cleaner.  That gives:
> 
> <initiator>
> 	<iqn>iqn.foo1.bar.baz</iqn>
> 	<iqn>iqn.foo2.bar.baz</iqn>
> 	<iqn>iqn.foo3.bar.baz</iqn>
> </initiator>
> 
> > Each initiator iqn name can be parsed to create the unique sessions.
> 

Fair enough.

> You should propose specifically how you see the sessions being set up.
> Each pool currently describes something that basically resembles a
> session, so your proposal modifies that paradigm a bit.  Another
> possible way to implement what you describe would be to allow zero or
> one initiator tags within a pool.  If no initiator tag is specified,
> the
> system will use the system default; if a tag is specified, the system
> will attempt to use the information contained in it.  The more I think
> about it, the more I like that approach since it keeps the pool
> paradigm
> unmodified.
>

Ok.
 
> > This should solve the following possibilities --
> >
> > * possibility of multiple IQNs for a single Guest
> > * option for Guest's own BIOS & initiator to use these IQNs (iSCSI
in
> > Guest)
> > * option for hypervisor's initiator to use these IQNs on behalf of
> the
> > guest
> > (Multi-IQN)
> 
> How is this different from the first possibility?
> 

The first possibility is usage 1 and 2(below) whereas the third
possibility is usage 3 and 4(below)

> >
> >
> > Compile tested only. Needs beatification.
> 
> I didn't go over the code closely, but I didn't see anything that
> struck
> me as completely off base.  I think it's more important to get the
> details of how this information will be used worked out at this point
> than to get the code finalized.
> 
> Dave

Example Usages:
Usage 1:
VM1 - > <Init iqn1> <------------------------> <Target iqn1>
        <Init iqn2> <------------------------> <Target iqn1>
        <Init iqn3> <------------------------> <Target iqn1>
        <Init iqn4> <------------------------> <Target iqn1>

Usage 2:
VM1 - > <Init iqn1> <------------------------> <Target iqn1>
        <Init iqn2> <------------------------> <Target iqn2>
        <Init iqn3> <------------------------> <Target iqn3>
        <Init iqn4> <------------------------> <Target iqn4>

Usage 3:
VM1 - > <Init iqn1> <------------------------> <Target iqn1>

VM2 - > <Init iqn2> <------------------------> <Target iqn1>

Usage 4:
VM1 - > <Init iqn1> <------------------------> <Target iqn1>

VM2 - > <Init iqn2> <------------------------> <Target iqn2>