domsch.com/linux/lfcs09/LFCS-Storage-Integration.odp This has also been discussed here. > -----Original Message----- > From: Iyer, Shyam > Sent: Tuesday, September 29, 2009 4:55 PM > To: 'Dave Allan' > Cc: libvir-list@xxxxxxxxxx; Bellad, Sudhir; Domsch, Matt; KM, Paniraja > Subject: RE: [libvirt] [RFC] Multi-IQN proposal > > > > -----Original Message----- > > From: Dave Allan [mailto:dallan@xxxxxxxxxx] > > Sent: Monday, September 28, 2009 6:44 PM > > To: Iyer, Shyam > > Cc: libvir-list@xxxxxxxxxx; Bellad, Sudhir; Domsch, Matt; KM, > Paniraja > > Subject: Re: [libvirt] [RFC] Multi-IQN proposal > > > > Shyam_Iyer@xxxxxxxx wrote: > > > 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> > > > > > > > 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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list