RE: [libvirt] [RFC] Multi-IQN proposal

-----Original Message----- From: Dave Allan [mailto:dallan@redhat.com] Sent: Monday, September 28, 2009 6:44 PM 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: > 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

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

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.

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

would be acceptable. Dave