[libvirt] [RFC] Multi-IQN proposal
Would this proposal be acceptable ? 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 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. diff --git a/src/storage_conf.c b/src/storage_conf.c index cb063cc..915e897 100644 --- a/src/storage_conf.c +++ b/src/storage_conf.c @@ -116,6 +116,7 @@ enum { VIR_STORAGE_POOL_SOURCE_DIR = (1<<2), VIR_STORAGE_POOL_SOURCE_ADAPTER = (1<<3), VIR_STORAGE_POOL_SOURCE_NAME = (1<<4), + VIR_STORAGE_POOL_SOURCE_INITIATOR_IQN = (1<<5), }; @@ -537,6 +538,33 @@ virStoragePoolDefParseXML(virConnectPtr conn, goto cleanup; } } + +/* Read the conf here */ + if (options->flags & VIR_STORAGE_POOL_SOURCE_INITATOR_IQN) { + int niqn, i; + + if ((niqn = virXPathNodeSet(conn, "./source/host/initiator", ctxt, &nodeset)) < 0) { + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("cannot extract storage pool source devices")); + goto cleanup; + } + if (VIR_ALLOC_N(ret->source.niqn, niqn) < 0) { + VIR_FREE(nodeset); + virReportOOMError(conn); + goto cleanup; + } + for (i = 0 ; i < niqn ; i++ ) { + xmlChar *name = xmlGetProp(nodeset[i], BAD_CAST "iqnname"); + if (path == NULL) { + VIR_FREE(nodeset); + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("missing storage pool source device path")); + goto cleanup; + } + ret->source.initiator[i].iqnname = (char *)name; + } + } if (options->flags & VIR_STORAGE_POOL_SOURCE_DEVICE) { xmlNodePtr *nodeset = NULL; int nsource, i; diff --git a/src/storage_conf.h b/src/storage_conf.h index 421d305..c2504be 100644 --- a/src/storage_conf.h +++ b/src/storage_conf.h @@ -202,7 +202,12 @@ struct _virStoragePoolSourceDevice { } geometry; }; - +/* Initiator Attributes */ +typedef virStoragePoolSourceInitiatorAttr *virStoragePoolSourceInitiatorAttrPtr; +struct virStoragePoolSourceInitiatorAttr { + char *iqnname; + /* We could put other initiator specific things here */ +} typedef struct _virStoragePoolSource virStoragePoolSource; typedef virStoragePoolSource *virStoragePoolSourcePtr; @@ -214,6 +219,9 @@ struct _virStoragePoolSource { int ndevice; virStoragePoolSourceDevicePtr devices; + /*And either one or more initiators*/ + virStoragePoolSourceInitiatorAttrPtr initiator; + /* Or a directory */ char *dir;
Do you also need to specify the expected mapping of initiator IQN to use for each target IQN, or is that not necessary? -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: Iyer, Shyam Sent: Friday, September 25, 2009 2:15 PM To: libvir-list@redhat.com Cc: Domsch, Matt; Bellad, Sudhir; KM, Paniraja Subject: [RFC] Multi-IQN proposal Would this proposal be acceptable ? 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 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. diff --git a/src/storage_conf.c b/src/storage_conf.c index cb063cc..915e897 100644 --- a/src/storage_conf.c +++ b/src/storage_conf.c @@ -116,6 +116,7 @@ enum { VIR_STORAGE_POOL_SOURCE_DIR = (1<<2), VIR_STORAGE_POOL_SOURCE_ADAPTER = (1<<3), VIR_STORAGE_POOL_SOURCE_NAME = (1<<4), + VIR_STORAGE_POOL_SOURCE_INITIATOR_IQN = (1<<5), }; @@ -537,6 +538,33 @@ virStoragePoolDefParseXML(virConnectPtr conn, goto cleanup; } } + +/* Read the conf here */ + if (options->flags & VIR_STORAGE_POOL_SOURCE_INITATOR_IQN) { + int niqn, i; + + if ((niqn = virXPathNodeSet(conn, "./source/host/initiator", ctxt, &nodeset)) < 0) { + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("cannot extract storage pool source devices")); + goto cleanup; + } + if (VIR_ALLOC_N(ret->source.niqn, niqn) < 0) { + VIR_FREE(nodeset); + virReportOOMError(conn); + goto cleanup; + } + for (i = 0 ; i < niqn ; i++ ) { + xmlChar *name = xmlGetProp(nodeset[i], BAD_CAST "iqnname"); + if (path == NULL) { + VIR_FREE(nodeset); + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("missing storage pool source device path")); + goto cleanup; + } + ret->source.initiator[i].iqnname = (char *)name; + } + } if (options->flags & VIR_STORAGE_POOL_SOURCE_DEVICE) { xmlNodePtr *nodeset = NULL; int nsource, i; diff --git a/src/storage_conf.h b/src/storage_conf.h index 421d305..c2504be 100644 --- a/src/storage_conf.h +++ b/src/storage_conf.h @@ -202,7 +202,12 @@ struct _virStoragePoolSourceDevice { } geometry; }; - +/* Initiator Attributes */ +typedef virStoragePoolSourceInitiatorAttr *virStoragePoolSourceInitiatorAttrPtr; +struct virStoragePoolSourceInitiatorAttr { + char *iqnname; + /* We could put other initiator specific things here */ +} typedef struct _virStoragePoolSource virStoragePoolSource; typedef virStoragePoolSource *virStoragePoolSourcePtr; @@ -214,6 +219,9 @@ struct _virStoragePoolSource { int ndevice; virStoragePoolSourceDevicePtr devices; + /*And either one or more initiators*/ + virStoragePoolSourceInitiatorAttrPtr initiator; + /* Or a directory */ char *dir;
-----Original Message----- From: Domsch, Matt Sent: Saturday, September 26, 2009 1:01 AM To: Iyer, Shyam; 'libvir-list@redhat.com' Cc: Bellad, Sudhir; KM, Paniraja Subject: RE: [RFC] Multi-IQN proposal
Do you also need to specify the expected mapping of initiator IQN to use for each target IQN, or is that not necessary?
That would not be necessary. The targets can do the mapping easily. Most targets today support initiator iqn based mapping.
Shyam_Iyer@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.
You should propose specifically how you see the sessions being set up. Each pool currently describes something that basically resembles a session, so your proposal modifies that paradigm a bit. Another possible way to implement what you describe would be to allow zero 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.
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?
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 the details of how this information will be used worked out at this point than to get the code finalized. Dave
diff --git a/src/storage_conf.c b/src/storage_conf.c index cb063cc..915e897 100644 --- a/src/storage_conf.c +++ b/src/storage_conf.c @@ -116,6 +116,7 @@ enum { VIR_STORAGE_POOL_SOURCE_DIR = (1<<2), VIR_STORAGE_POOL_SOURCE_ADAPTER = (1<<3), VIR_STORAGE_POOL_SOURCE_NAME = (1<<4), + VIR_STORAGE_POOL_SOURCE_INITIATOR_IQN = (1<<5), };
@@ -537,6 +538,33 @@ virStoragePoolDefParseXML(virConnectPtr conn, goto cleanup; } } + +/* Read the conf here */ + if (options->flags & VIR_STORAGE_POOL_SOURCE_INITATOR_IQN) { + int niqn, i; + + if ((niqn = virXPathNodeSet(conn, "./source/host/initiator", ctxt, &nodeset)) < 0) { + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("cannot extract storage pool source devices")); + goto cleanup; + } + if (VIR_ALLOC_N(ret->source.niqn, niqn) < 0) { + VIR_FREE(nodeset); + virReportOOMError(conn); + goto cleanup; + } + for (i = 0 ; i < niqn ; i++ ) { + xmlChar *name = xmlGetProp(nodeset[i], BAD_CAST "iqnname"); + if (path == NULL) { + VIR_FREE(nodeset); + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("missing storage pool source device path")); + goto cleanup; + } + ret->source.initiator[i].iqnname = (char *)name; + } + } if (options->flags & VIR_STORAGE_POOL_SOURCE_DEVICE) { xmlNodePtr *nodeset = NULL; int nsource, i; diff --git a/src/storage_conf.h b/src/storage_conf.h index 421d305..c2504be 100644 --- a/src/storage_conf.h +++ b/src/storage_conf.h @@ -202,7 +202,12 @@ struct _virStoragePoolSourceDevice { } geometry; };
- +/* Initiator Attributes */ +typedef virStoragePoolSourceInitiatorAttr *virStoragePoolSourceInitiatorAttrPtr; +struct virStoragePoolSourceInitiatorAttr { + char *iqnname; + /* We could put other initiator specific things here */ +}
typedef struct _virStoragePoolSource virStoragePoolSource; typedef virStoragePoolSource *virStoragePoolSourcePtr; @@ -214,6 +219,9 @@ struct _virStoragePoolSource { int ndevice; virStoragePoolSourceDevicePtr devices;
+ /*And either one or more initiators*/ + virStoragePoolSourceInitiatorAttrPtr initiator; + /* Or a directory */ char *dir;
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----Original Message----- From: Dave Allan [mailto:dallan@redhat.com] Sent: Saturday, September 26, 2009 2:43 AM To: Iyer, Shyam Cc: libvir-list@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer@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
Thanks for the review. 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 set up. Each pool currently describes something that basically resembles a session, so your proposal modifies that paradigm a bit. Another possible way to implement what you describe would be to allow zero 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 the 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>
Shyam_Iyer@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@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer@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 set up. Each pool currently describes something that basically resembles a session, so your proposal modifies that paradigm a bit. Another possible way to implement what you describe would be to allow zero 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 the 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. Your statement about providing the iqn to the guest to be used by its 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 pool started on the host in such a case. Libvirt currently has no support 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
-----Original Message----- From: Dave Allan [mailto:dallan@redhat.com] Sent: Monday, September 28, 2009 6:44 PM To: Iyer, Shyam Cc: libvir-list@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
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@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer@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 set up. Each pool currently describes something that basically resembles a session, so your proposal modifies that paradigm a bit. Another possible way to implement what you describe would be to allow zero 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
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 the details of how this information will be used worked out at this
Shyam_Iyer@Dell.com wrote: think 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 its 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 pool started on the host in such a case. Libvirt currently has no support 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
-----Original Message----- From: Iyer, Shyam Sent: Tuesday, September 29, 2009 4:55 PM To: 'Dave Allan' Cc: libvir-list@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@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
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@redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer@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 set up. Each pool currently describes something that basically resembles a session, so your proposal modifies that paradigm a bit. Another possible way to implement what you describe would be to allow zero 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
Shyam_Iyer@Dell.com wrote: 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 its 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
domsch.com/linux/lfcs09/LFCS-Storage-Integration.odp This has also been discussed here. the pool
started on the host in such a case. Libvirt currently has no support 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
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 :|
-----Original Message----- From: libvir-list-bounces@redhat.com [mailto:libvir-list- bounces@redhat.com] On Behalf Of Daniel P. Berrange Sent: Monday, September 28, 2009 4:47 PM To: Iyer, Shyam Cc: libvir-list@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@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;
participants (4)
-
Daniel P. Berrange -
Dave Allan -
Matt_Domsch＠Dell.com -
Shyam_Iyer＠Dell.com