RE: [libvirt] [RFC] Multi-IQN proposal
Thanks for the review.
-----Original Message-----
From: Dave Allan [mailto:dallan@redhat.com]
Sent: Saturday, September 26, 2009 2:43 AM
To: Iyer, Shyam
Cc: libvir-list(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer(a)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>