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