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

-----Original Message----- From: Iyer, Shyam Sent: Tuesday, September 29, 2009 4:55 PM To: 'Dave Allan' Cc: libvir-list(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: 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

> up. > >> Each pool currently describes something that basically resembles

> >> session, so your proposal modifies that paradigm a bit. Another > >> possible way to implement what you describe would be to allow

> 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

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

> 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

> started on the host in such a case. Libvirt currently has no

> 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