2:15 p.m.
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;
2:31 p.m.
New subject: [libvirt] 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?
--
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(a)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;
2:36 p.m.
New subject: [libvirt] RE: [RFC] Multi-IQN proposal
-----Original Message-----
From: Domsch, Matt
Sent: Saturday, September 26, 2009 1:01 AM
To: Iyer, Shyam; 'libvir-list(a)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.
4:13 p.m.
Shyam_Iyer(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
12:45 a.m.
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(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer(a)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>
8:13 a.m.
Shyam_Iyer(a)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(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
>
> Shyam_Iyer(a)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
6:25 a.m.
-----Original Message-----
From: Dave Allan [mailto:dallan@redhat.com]
Sent: Monday, September 28, 2009 6:44 PM
To: Iyer, Shyam
Cc: libvir-list(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
Subject: Re: [libvirt] [RFC] Multi-IQN proposal
Shyam_Iyer(a)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(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM,
Paniraja
>> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
>>
>> Shyam_Iyer(a)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.
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
12:09 p.m.
domsch.com/linux/lfcs09/LFCS-Storage-Integration.odp
This has also been discussed here.
-----Original Message-----
From: Iyer, Shyam
Sent: Tuesday, September 29, 2009 4:55 PM
To: 'Dave Allan'
Cc: libvir-list(a)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(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM,
Paniraja
> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
>
> Shyam_Iyer(a)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(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM,
> Paniraja
> >> Subject: Re: [libvirt] [RFC] Multi-IQN proposal
> >>
> >> Shyam_Iyer(a)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.
>
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
6:17 a.m.
On Sat, Sep 26, 2009 at 12:45:03AM +0530, Shyam_Iyer(a)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 :|
5:36 a.m.
-----Original Message-----
From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-
bounces(a)redhat.com] On Behalf Of Daniel P. Berrange
Sent: Monday, September 28, 2009 4:47 PM
To: Iyer, Shyam
Cc: libvir-list(a)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(a)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;
5525
days inactive
5536
days old
9 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Dave Allan -
Matt_Domsch＠Dell.com -
Shyam_Iyer＠Dell.com