[libvirt] [RFC] Multi-IQN proposal

[Shyam_Iyer at Dell.com]

domsch.com/linux/lfcs09/LFCS-Storage-Integration.odp

This has also been discussed here. 

> -----Original Message-----
> From: Iyer, Shyam
> Sent: Tuesday, September 29, 2009 4:55 PM
> To: 'Dave Allan'
> Cc: libvir-list at redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
> Subject: RE: [libvirt] [RFC] Multi-IQN proposal
> 
> 
> > -----Original Message-----
> > From: Dave Allan [mailto:dallan at redhat.com]
> > Sent: Monday, September 28, 2009 6:44 PM
> > 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:
> > > 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>
> > >
> >
> > Ok, I see what you mean now.  From libvirt's perspective, there's no
> > difference between these cases; you would simply be starting a bunch
> of
> > pools and assigning the volumes to the appropriate guest(s).  I am
> > concerned now that you are proposing something larger than simply
> > providing support for libvirt to use more than one iqn when starting
> > pools on a host.  As Dan Berrange also requested, please explain
> > exactly
> > how you intend for this functionality to be used.
> >
> 
> Replied to Dan's request.
> 
> Idea is to reduce iSCSI manageability windows.
> 
> Virt-manager or any management app that uses libvirt should be used by
> user to just provide initiator iqns.
> 
> 
> > Your statement about providing the iqn to the guest to be used by
its
> > BIOS is particularly unclear to me.  I understand what you want to
> do,
> > but how do you envision that process working?  There would be no
pool
> > started on the host in such a case.  Libvirt currently has no
support
> > for such an operation, so you should explain exactly what you're
> > proposing before you try to implement it.  I don't know enough about
> > what you're proposing to provide an opinion at this point on whether
> it
> > would be acceptable.
> >
> > Dave
> 
> Typically if the iqn could be fed into the the gpxe option rom as a
> default initiator iqn(gPXEs understand iBFT today) then the iSCSI
> session would be started by the guest nic option-rom using user
> provided iqns.
> 
> Probably something like this -
> 
> qemu-kvm -m 512 boot n -nic --option-rom <rom-image> --iqn <iqn name>
> ......
> 
> And also passed through the virt-manager ...
> 
> -Shyam