On Sat, Sep 26, 2009 at 12:45:03AM +0530, Shyam_Iyer@Dell.com wrote:
Would this proposal be acceptable ?
It is hard to say. Can you try and explain what it actually does, and/or what you are trying to achieve ? Googling for more docs / info about 'Multi-IQN' returns this mailing thread as the top hit which doesn't really help understanding.
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>
Each initiator iqn name can be parsed to create the unique sessions.
This doesn't make a whole lot of sense - for each iSCSI storage pool defined in libvirt there is exactly one iSCSI session. So I'm not really following why we'd need multiple IQN names in a single pool if that were to imply in multiple sessions. Ultimately a storage pool in libvirt is all about listing volumes, and optionally creating/deleting volumes. iSCSI pools can only list volumes, where each volume corresponds to a LUN in the iSCSI target configured for the pool. So what effect does Multi-IQN have on the process of enumerating LUNs ?
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)
Compile tested only. Needs beatification.
The patch doesn't seem to actually do anything beyond parsing the extra XML data - what is it actually to be used for in the iSCSI storage implementation in storage_backend_iscsi.c ? Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|