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>