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

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. 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. in 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;