[libvirt] [RFC] Multi-IQN proposal

[Shyam_Iyer at Dell.com]

> -----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