[libvirt] [RFC] Multi-IQN proposal

[Daniel P. Berrange]

On Sat, Sep 26, 2009 at 12:45:03AM +0530, Shyam_Iyer at 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 :|