[libvirt] [RFC] Multi-IQN proposal

[Shyam_Iyer at Dell.com]

> -----Original Message-----
> From: libvir-list-bounces at redhat.com [mailto:libvir-list-
> bounces at redhat.com] On Behalf Of Daniel P. Berrange
> Sent: Monday, September 28, 2009 4:47 PM
> To: Iyer, Shyam
> Cc: libvir-list at redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
> 
> 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.

Extending the pool concept to multiple sessions opens up different
possibilities. Already the pool enumerates the different LUNs behind the
Target IQN.
Extending the mesh at the initiator side just opens up new combinations
with added advantages.
 
Multi-iqn offers flexibility to split I/Os by unique sessions and thus
allows for better manageability.

Today the open-iscsi initiator can create multi-IQN iSCSI sessions by
using ifaces.

See example /etc/iscsi/iface configuration file.
"
iface.transport_name = tcp
iface.initiatorname = iqn.2003-04.com.fedora:test
"
#iscsiadm -m node -T <target iqn name> -I <iface_conf> -l
<-----------------This could be a backend command.

Extending this flexibility to the VMs offer per VM manageability.


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


Since Multi-IQN is enumerating a new session it is no different from a
multipathing concept. A new LUN will be enumerated for each unique
IQN-pair and will have a unique /dev/sdX path.


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

Planning to propose something like this but I wanted a consensus on the
XML schema first.

diff --git a/src/storage_backend_iscsi.c b/src/storage_backend_iscsi.c
index b516add..222eb33 100644
--- a/src/storage_backend_iscsi.c
+++ b/src/storage_backend_iscsi.c
@@ -157,13 +157,25 @@ static int
 virStorageBackendISCSIConnection(virConnectPtr conn,
                                  virStoragePoolObjPtr pool,
                                  const char *portal,
-                                 const char *action)
+                                 const char *action, int ifaces)
 {
+/* Somehow this logic has to get better
+ * Things to note:
+ * 1) How to pass ifaces are configured?
+ * 2) How to run loop to login to each of the iface provided initiator
iqn names
+ * */
+if (ifaces) {
+    const char *const cmdargv[] = {
+        ISCSIADM, "--mode", "node", "--portal", portal,
+        "--targetname", pool->def->source.devices[0].path, "-I",
pool->def->source.initiator[0].iqnname, action, NULL
+    };
+}
+else {
     const char *const cmdargv[] = {
         ISCSIADM, "--mode", "node", "--portal", portal,
         "--targetname", pool->def->source.devices[0].path, action, NULL
     };
-
+}
     if (virRun(conn, cmdargv, NULL) < 0)
         return -1;