[Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case
This is a multi-part message in MIME format. --------------040206010801040103040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I by mistake sent this earlier to users@ovirt I think the right list is engine-devel, hence resending. Sorry for the mispost earlier. -------- Original Message -------- Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Date: Mon, 18 Mar 2013 20:23:57 +0530 From: Deepak C Shetty <deepakcs@linux.vnet.ibm.com> Organization: IBM India Pvt. Ltd. To: users@ovirt.org <users@ovirt.org>, Sharad Mishra <snmishra@us.ibm.com> Hi All, I am validating GLUSTERFS Storage domain engine patches (worked on by Sharad, in Cc) as posted here... http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+t... against VDSM Glusterfs domain support (already upstream in VDSM) I see the below issue as part of me creatign a new Gluster Storage DOmain in the UI Engine logs... 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d VDSM Logs... Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None)*--> Notice no vfs_type here !!!* VDSM doesn't recv. the vfs_type in the conList dict !!! I had this small chat with Saggi of VDSM, just to confirm that there isn't a possibility that VDSM might be stripping args that are recd. from Engine.. and it doesn't. --------------------------------------------------------------------------------------------------------------------- <deepakcs> saggi, Hi <saggi> deepakcs: hi <deepakcs> saggi, Is it possible that VDSM might strip down some of the connparams that are recd. as part of connectStorageServer ? <deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being passed, but connectStorageServer log doesn't show vfs_type in the params dict <deepakcs> saggi, so wodering where vfs_type is getting dropped in this whole process <saggi> Probably not being sent <saggi> if it's not being logged <deepakcs> saggi, engine log has this.... <deepakcs> 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul <deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d <deepakcs> saggi, on VDSM side i see this... <deepakcs> Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) --> Notice no vfs_type here !!! <saggi> Then you are not sending the correct connection type <deepakcs> saggi, 'you' means the engine side of code ? engine patches is being done by Sharad, and I amtrying to work with them on this issue <deepakcs> saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on that front <saggi> If it show nfsRetrans you are using nfs which doesn't have a vfs_type argument <deepakcs> saggi, but engine log says storageType = GLUSTERFS <deepakcs> saggi, maybe i can send mail to users@ovirt list to see if anybody can provide more clues <deepakcs> saggi, but definitely this doesn't looks like a vdsm side of issue rite ? <saggi> We log the params as we get them <deepakcs> saggi, right, thats what i also see.. just wanted to confirm once with you, before i sent mail to ovirt folks --------------------------------------------------------------------------------------------------------------------- Can someone help provide any clues on what might be the issue here ? Because VDSM doesn't see vfs_type, the connectStorageServer fails and hence new SD cannot be created ! thanx, deepak --------------040206010801040103040709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <tt>I by mistake sent this earlier to users@ovirt<br> I think the right list is engine-devel, hence resending. Sorry for the mispost earlier.<br> </tt> <div class="moz-forward-container"><br> <br> -------- Original Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th> <td>vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th> <td>Mon, 18 Mar 2013 20:23:57 +0530</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th> <td>Deepak C Shetty <a class="moz-txt-link-rfc2396E" href="mailto:deepakcs@linux.vnet.ibm.com"><deepakcs@linux.vnet.ibm.com></a></td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organization: </th> <td>IBM India Pvt. Ltd.</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th> <td><a class="moz-txt-link-abbreviated" href="mailto:users@ovirt.org">users@ovirt.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:users@ovirt.org"><users@ovirt.org></a>, Sharad Mishra <a class="moz-txt-link-rfc2396E" href="mailto:snmishra@us.ibm.com"><snmishra@us.ibm.com></a></td> </tr> </tbody> </table> <br> <br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <tt>Hi All,<br> I am validating GLUSTERFS Storage domain engine patches (worked on by Sharad, in Cc) as posted here...<br> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z">http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z</a><br> against VDSM Glusterfs domain support (already upstream in VDSM)<br> <br> I see the below issue as part of me creatign a new Gluster Storage DOmain in the UI<br> <br> Engine logs...<br> <br> 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d<br> <br> VDSM Logs...<br> <br> Thread-77::<a moz-do-not-send="true" class="moz-txt-link-freetext" href="INFO::2013-03-18">INFO::2013-03-18</a> 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None)<b> --> Notice no vfs_type here !!!</b><br> <br> VDSM doesn't recv. the vfs_type in the conList dict !!!<br> <br> I had this small chat with Saggi of VDSM, just to confirm that there isn't a possibility that VDSM might be stripping args that are recd. from Engine.. and it doesn't.<br> <br> </tt><br> <tt><tt>---------------------------------------------------------------------------------------------------------------------<br> </tt><deepakcs> saggi, Hi<br> <saggi> deepakcs: hi<br> <br> <deepakcs> saggi, Is it possible that VDSM might strip down some of the connparams that are recd. as part of connectStorageServer ?<br> <deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being passed, but connectStorageServer log doesn't show vfs_type in the params dict<br> <deepakcs> saggi, so wodering where vfs_type is getting dropped in this whole process<br> <saggi> Probably not being sent<br> <saggi> if it's not being logged<br> <deepakcs> saggi, engine log has this....<br> <deepakcs> 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul<br> <deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d<br> <deepakcs> saggi, on VDSM side i see this...<br> <deepakcs> Thread-77::<a moz-do-not-send="true" class="moz-txt-link-freetext" href="INFO::2013-03-18">INFO::2013-03-18</a> 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) --> Notice no vfs_type here !!!<br> <saggi> Then you are not sending the correct connection type<br> <br> <deepakcs> saggi, 'you' means the engine side of code ? engine patches is being done by Sharad, and I amtrying to work with them on this issue<br> <br> <deepakcs> saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on that front<br> <saggi> If it show nfsRetrans you are using nfs which doesn't have a vfs_type argument<br> <deepakcs> saggi, but engine log says storageType = GLUSTERFS<br> <deepakcs> saggi, maybe i can send mail to users@ovirt list to see if anybody can provide more clues<br> <deepakcs> saggi, but definitely this doesn't looks like a vdsm side of issue rite ?<br> <saggi> We log the params as we get them<br> <br> <deepakcs> saggi, right, thats what i also see.. just wanted to confirm once with you, before i sent mail to ovirt folks<br> <br> ---------------------------------------------------------------------------------------------------------------------<br> <br> <br> Can someone help provide any clues on what might be the issue here ?<br> Because VDSM doesn't see vfs_type, the connectStorageServer fails and hence new SD cannot be created !<br> <br> thanx,<br> deepak<br> <br> </tt><br> <br> </div> <br> </body> </html> --------------040206010801040103040709--
Deepak, I suspect it's related to the following code snippet. // storage_pool can be null when discovering iscsi send targets or when connecting // through vds which has no storage pool if (storage_pool == null || Config.<Boolean> GetValue(ConfigValues.AdvancedNFSOptionsEnabled, storage_pool.getcompatibility_version().getValue())) { // For mnt_options, vfs_type, and protocol_version - if they are null // or empty we should not send a key with an empty value ... con.putIfNotEmpty("vfs_type", connection.getVfsType()); ... } If my understanding is correct, AdvancedNFSOptionsEnabled is true only for DC 3.1 and 3.2. What's your DC version? It should be 3.2, otherwise it could not be compatible with glusterfs domain. Anyway, you could add some debugging code to see if the 'vfsType' options is added to parameters. You also could use wireshark confirm if it's sent by ovirt-engine. Of course, you need disable SSL at first before capturing packets. Don't blame me if it doesn't help at all. :-) Mark. On Mon 18 Mar 2013 10:56:59 PM CST, Deepak C Shetty wrote:
I by mistake sent this earlier to users@ovirt I think the right list is engine-devel, hence resending. Sorry for the mispost earlier.
-------- Original Message -------- Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Date: Mon, 18 Mar 2013 20:23:57 +0530 From: Deepak C Shetty <deepakcs@linux.vnet.ibm.com> Organization: IBM India Pvt. Ltd. To: users@ovirt.org <users@ovirt.org>, Sharad Mishra <snmishra@us.ibm.com>
Hi All, I am validating GLUSTERFS Storage domain engine patches (worked on by Sharad, in Cc) as posted here... http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+t... against VDSM Glusterfs domain support (already upstream in VDSM)
I see the below issue as part of me creatign a new Gluster Storage DOmain in the UI
Engine logs...
2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d
VDSM Logs...
Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None)*--> Notice no vfs_type here !!!*
VDSM doesn't recv. the vfs_type in the conList dict !!!
I had this small chat with Saggi of VDSM, just to confirm that there isn't a possibility that VDSM might be stripping args that are recd. from Engine.. and it doesn't.
--------------------------------------------------------------------------------------------------------------------- <deepakcs> saggi, Hi <saggi> deepakcs: hi
<deepakcs> saggi, Is it possible that VDSM might strip down some of the connparams that are recd. as part of connectStorageServer ? <deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being passed, but connectStorageServer log doesn't show vfs_type in the params dict <deepakcs> saggi, so wodering where vfs_type is getting dropped in this whole process <saggi> Probably not being sent <saggi> if it's not being logged <deepakcs> saggi, engine log has this.... <deepakcs> 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul <deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d <deepakcs> saggi, on VDSM side i see this... <deepakcs> Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) --> Notice no vfs_type here !!! <saggi> Then you are not sending the correct connection type
<deepakcs> saggi, 'you' means the engine side of code ? engine patches is being done by Sharad, and I amtrying to work with them on this issue
<deepakcs> saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on that front <saggi> If it show nfsRetrans you are using nfs which doesn't have a vfs_type argument <deepakcs> saggi, but engine log says storageType = GLUSTERFS <deepakcs> saggi, maybe i can send mail to users@ovirt list to see if anybody can provide more clues <deepakcs> saggi, but definitely this doesn't looks like a vdsm side of issue rite ? <saggi> We log the params as we get them
<deepakcs> saggi, right, thats what i also see.. just wanted to confirm once with you, before i sent mail to ovirt folks
---------------------------------------------------------------------------------------------------------------------
Can someone help provide any clues on what might be the issue here ? Because VDSM doesn't see vfs_type, the connectStorageServer fails and hence new SD cannot be created !
thanx, deepak
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--0__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C Content-type: multipart/alternative; Boundary="1__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C" --1__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Mark, You are correct. The issue was with that piece of code. A patch has been posted to fix it - http://gerrit.ovirt.org/#/c/13155/ Thanks Sharad Mishra Open Virtualization Linux Technology Center IBM From: Mark Wu <wudxw@linux.vnet.ibm.com> To: Deepak C Shetty <deepakcs@linux.vnet.ibm.com>, Cc: "engine-devel@ovirt.org" <engine-devel@ovirt.org>, Sharad Mishra/Beaverton/IBM@IBMUS Date: 03/18/13 07:45 PM Subject: Re: [Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Deepak, I suspect it's related to the following code snippet. // storage_pool can be null when discovering iscsi send targets= or when connecting // through vds which has no storage pool if (storage_pool =3D=3D null || Config.<Boolean> GetValue(ConfigValues.AdvancedNFSOptionsEnabled, storage_pool.getcompatibility_version().getValue())) { // For mnt_options, vfs_type, and protocol_version - if they are null // or empty we should not send a key with an empty value ... con.putIfNotEmpty("vfs_type", connection.getVfsType()); ... } If my understanding is correct, AdvancedNFSOptionsEnabled is true only for DC 3.1 and 3.2. What's your DC version? It should be 3.2, otherwise it could not be compatible with glusterfs domain. Anyway, you could add some debugging code to see if the 'vfsType' options is added to parameters. You also could use wireshark confirm if it's sent by ovirt-engine. Of course, you need disable SSL at first before capturing packets. Don't blame me if it doesn't help at all. :-) Mark. On Mon 18 Mar 2013 10:56:59 PM CST, Deepak C Shetty wrote:
I by mistake sent this earlier to users@ovirt I think the right list is engine-devel, hence resending. Sorry for th= e mispost earlier.
-------- Original Message -------- Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Date: Mon, 18 Mar 2013 20:23:57 +0530 From: Deepak C Shetty <deepakcs@linux.vnet.ibm.com> Organization: IBM India Pvt. Ltd. To: users@ovirt.org <users@ovirt.org>, Sharad Mishra <snmishra@us.ibm.com>
Hi All, I am validating GLUSTERFS Storage domain engine patches (worked o= n by Sharad, in Cc) as posted here... http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine +branch:master+topic:glusterfs,n,z against VDSM Glusterfs domain support (already upstream in VDSM)
I see the below issue as part of me creatign a new Gluster Storage DOmain in the UI
Engine logs...
2013-03-18 13:27:29,149 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSComma= nd]
(http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName =3D vm-vdsm-de-1, HostId =3D c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId =3D 00000000-0000-0000-0000-000000000000, storageType =3D GLUSTERFS, connectionList =3D [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn= : null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d
VDSM Logs...
Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=3D7, spUUID=3D'00000000-0000-0000-0000-000000000000', conList=3D[{'connect= ion': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=3DNone)*--> Notice no vfs_type here !!!*
VDSM doesn't recv. the vfs_type in the conList dict !!!
I had this small chat with Saggi of VDSM, just to confirm that there isn't a possibility that VDSM might be stripping args that are recd. from Engine.. and it doesn't.
-----------------------------------------------------------------------= ----------------------------------------------
<deepakcs> saggi, Hi <saggi> deepakcs: hi
<deepakcs> saggi, Is it possible that VDSM might strip down some of the connparams that are recd. as part of connectStorageServer ? <deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being passed, but connectStorageServer log doesn't show vfs_type in the params dict <deepakcs> saggi, so wodering where vfs_type is getting dropped in this whole process <saggi> Probably not being sent <saggi> if it's not being logged <deepakcs> saggi, engine log has this.... <deepakcs> 2013-03-18 13:27:29,149 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSComma= nd]
(http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName =3D vm-vdsm-de-1, HostId =3D c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId =3D 00000000-0000-0000-0000-000000000000, storageType =3D GLUSTERFS, connectionList =3D [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn= : null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul <deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d <deepakcs> saggi, on VDSM side i see this... <deepakcs> Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=3D7, spUUID=3D'00000000-0000-0000-0000-000000000000', conList=3D[{'connect= ion': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=3DNone) --> Notice no vfs_type here !!! <saggi> Then you are not sending the correct connection type
<deepakcs> saggi, 'you' means the engine side of code ? engine patche= s is being done by Sharad, and I amtrying to work with them on this iss= ue
<deepakcs> saggi, domType=3D7 is GLUSTERFS_DOMAIN, so its correct on that front <saggi> If it show nfsRetrans you are using nfs which doesn't have a vfs_type argument <deepakcs> saggi, but engine log says storageType =3D GLUSTERFS <deepakcs> saggi, maybe i can send mail to users@ovirt list to see if=
anybody can provide more clues <deepakcs> saggi, but definitely this doesn't looks like a vdsm side of issue rite ? <saggi> We log the params as we get them
<deepakcs> saggi, right, thats what i also see.. just wanted to confirm once with you, before i sent mail to ovirt folks
-----------------------------------------------------------------------= ----------------------------------------------
Can someone help provide any clues on what might be the issue here ? Because VDSM doesn't see vfs_type, the connectStorageServer fails and=
hence new SD cannot be created !
thanx, deepak
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
= --1__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><font size=3D"2" face=3D"sans-serif">Mark,</font><br> <br> <font size=3D"2" face=3D"sans-serif"> You are correct. The issue was wi= th that piece of code. A patch has been posted to fix it - <a href=3D"h= ttp://gerrit.ovirt.org/#/c/13155/">http://gerrit.ovirt.org/#/c/13155/</= a></font><br> <br> <font size=3D"2" face=3D"sans-serif">Thanks</font><br> <font size=3D"2" face=3D"sans-serif">Sharad Mishra<br> Open Virtualization<br> Linux Technology Center<br> IBM</font><br> <br> <img width=3D"16" height=3D"16" src=3D"cid:1__=3D08BBF1A0DF870F1C8f9e8a= 93df938@us.ibm.com" border=3D"0" alt=3D"Inactive hide details for Mark = Wu ---03/18/2013 07:45:35 PM---Deepak, I suspect it's related to the fo= llowing code snippet."><font size=3D"2" color=3D"#424282" face=3D"sans-= serif">Mark Wu ---03/18/2013 07:45:35 PM---Deepak, I suspect it's relat= ed to the following code snippet.</font><br> <br> <font size=3D"1" color=3D"#5F5F5F" face=3D"sans-serif">From: </font><fo= nt size=3D"1" face=3D"sans-serif">Mark Wu <wudxw@linux.vnet.ibm.com&= gt;</font><br> <font size=3D"1" color=3D"#5F5F5F" face=3D"sans-serif">To: </font><font= size=3D"1" face=3D"sans-serif">Deepak C Shetty <deepakcs@linux.vnet= .ibm.com>, </font><br> <font size=3D"1" color=3D"#5F5F5F" face=3D"sans-serif">Cc: </font><font= size=3D"1" face=3D"sans-serif">"engine-devel@ovirt.org" <= engine-devel@ovirt.org>, Sharad Mishra/Beaverton/IBM@IBMUS</font><br=
<font size=3D"1" color=3D"#5F5F5F" face=3D"sans-serif">Date: </font><fo= nt size=3D"1" face=3D"sans-serif">03/18/13 07:45 PM</font><br> <font size=3D"1" color=3D"#5F5F5F" face=3D"sans-serif">Subject: </font>= <font size=3D"1" face=3D"sans-serif">Re: [Engine-devel] vfs_type not be= ing sent by engine to VDSM for GLUSTER DOMAIN case</font><br> <hr width=3D"100%" size=3D"2" align=3D"left" noshade style=3D"color:#80= 91A5; "><br> <br> <br> <tt><font size=3D"2">Deepak,<br> <br> I suspect it's related to the following code snippet.<br> <br> // storage_pool can be null when discoverin= g iscsi send targets <br> or when connecting<br> // through vds which has no storage pool<br=
if (storage_pool =3D=3D null || Config.<= Boolean> <br> GetValue(ConfigValues.AdvancedNFSOptionsEnabled,<br> storage_pool.ge= tcompatibility_version().getValue())) {<br> // For mnt_options, vfs_type,= and protocol_version - if <br> they are null<br> // or empty we should not sen= d a key with an empty value<br> ...<br> con.putIfNotEmpty("vfs_t= ype", connection.getVfsType());<br> ...<br> }<br> <br> If my understanding is correct, AdvancedNFSOptionsEnabled is true only = <br> for DC 3.1 and 3.2. What's your DC version?<br> It should be 3.2, otherwise it could not be compatible with glusterfs <= br> domain. Anyway, you could add some debugging code<br> to see if the 'vfsType' options is added to parameters. You also could = <br> use wireshark confirm if it's sent by ovirt-engine.<br> Of course, you need disable SSL at first before capturing packets.<br> <br> Don't blame me if it doesn't help at all. :-)<br> <br> Mark.<br> <br> <br> <br> <br> <br> <br> <br> On Mon 18 Mar 2013 10:56:59 PM CST, Deepak C Shetty wrote:<br> > I by mistake sent this earlier to users@ovirt<br> > I think the right list is engine-devel, hence resending. Sorry for= the<br> > mispost earlier.<br> ><br> ><br> > -------- Original Message --------<br> > Subject: vfs_type not being sent by engine to VDSM for GLUSTER = DOMAIN<br> > case<br> > Date: Mon, 18 Mar 2013 20:23:57 +0530<br> > From: Deepak C Shetty <deepakcs@linux.vnet.ibm.com><br> > Organization: IBM India Pvt. Ltd.<br> > To: users@ovirt.org <users@ovirt.org>, Sharad Mishra<br> > <snmishra@us.ibm.com><br> ><br> ><br> ><br> > Hi All,<br> > I am validating GLUSTERFS Storage domain engine patc= hes (worked on<br> > by Sharad, in Cc) as posted here...<br> > </font></tt><tt><font size=3D"2"><a href=3D"http://gerrit.ovirt.or= g/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,= z">http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:= master+topic:glusterfs,n,z</a></font></tt><tt><font size=3D"2"><br> > against VDSM Glusterfs domain support (already upstream in VDSM)<b= r> ><br> > I see the below issue as part of me creatign a new Gluster Storage= <br> > DOmain in the UI<br> ><br> > Engine logs...<br> ><br> > 2013-03-18 13:27:29,149 INFO<br> > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDS= Command]<br> > (http--0.0.0.0-8700-1) [4b751967] START,<br> > ConnectStorageServerVDSCommand(HostName =3D vm-vdsm-de-1, HostId =3D= <br> > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId =3D<br> > 00000000-0000-0000-0000-000000000000, storageType =3D GLUSTERFS,<b= r> > connectionList =3D [{ id: null, connection: vm-vdsm-de-1:dpkvol4, = iqn:<br> > null, vfsType: glusterfs, mountOptions: null, nfsVersion: null,<br=
> nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d<br> ><br> > VDSM Logs...<br> ><br> > Thread-77::INFO::2013-03-18<br> > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect:= <br> > connectStorageServer(domType=3D7,<br> > spUUID=3D'00000000-0000-0000-0000-000000000000', conList=3D[{'conn= ection':<br> > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '',<br> > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'= ,<br> > 'port': ''}], options=3DNone)*--> Notice no vfs_type here !!!*<= br> ><br> > VDSM doesn't recv. the vfs_type in the conList dict !!!<br> ><br> > I had this small chat with Saggi of VDSM, just to confirm that the= re<br> > isn't a possibility that VDSM might be stripping args that are rec= d.<br> > from Engine.. and it doesn't.<br> ><br> ><br> > ------------------------------------------------------------------= ---------------------------------------------------<br> > <deepakcs> saggi, Hi<br> > <saggi> deepakcs: hi<br> ><br> > <deepakcs> saggi, Is it possible that VDSM might strip down = some of<br> > the connparams that are recd. as part of connectStorageServer ?<br=
> <deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see v= fsType<br> > being passed, but connectStorageServer log doesn't show vfs_type i= n<br> > the params dict<br> > <deepakcs> saggi, so wodering where vfs_type is getting drop= ped in<br> > this whole process<br> > <saggi> Probably not being sent<br> > <saggi> if it's not being logged<br> > <deepakcs> saggi, engine log has this....<br> > <deepakcs> 2013-03-18 13:27:29,149 INFO<br> > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDS= Command]<br> > (http--0.0.0.0-8700-1) [4b751967] START,<br> > ConnectStorageServerVDSCommand(HostName =3D vm-vdsm-de-1, HostId =3D= <br> > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId =3D<br> > 00000000-0000-0000-0000-000000000000, storageType =3D GLUSTERFS,<b= r> > connectionList =3D [{ id: null, connection: vm-vdsm-de-1:dpkvol4, = iqn:<br> > null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul<br> > <deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id:= f88d42d<br> > <deepakcs> saggi, on VDSM side i see this...<br> > <deepakcs> Thread-77::INFO::2013-03-18<br> > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect:= <br> > connectStorageServer(domType=3D7,<br> > spUUID=3D'00000000-0000-0000-0000-000000000000', conList=3D[{'conn= ection':<br> > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '',<br> > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'= ,<br> > 'port': ''}], options=3DNone) --> Notice no vfs_type here !!!<b= r> > <saggi> Then you are not sending the correct connection type= <br> ><br> > <deepakcs> saggi, 'you' means the engine side of code ? engi= ne patches<br> > is being done by Sharad, and I amtrying to work with them on this = issue<br> ><br> > <deepakcs> saggi, domType=3D7 is GLUSTERFS_DOMAIN, so its co= rrect on<br> > that front<br> > <saggi> If it show nfsRetrans you are using nfs which doesn'= t have a<br> > vfs_type argument<br> > <deepakcs> saggi, but engine log says storageType =3D GLUSTE= RFS<br> > <deepakcs> saggi, maybe i can send mail to users@ovirt list = to see if<br> > anybody can provide more clues<br> > <deepakcs> saggi, but definitely this doesn't looks like a v= dsm side<br> > of issue rite ?<br> > <saggi> We log the params as we get them<br> ><br> > <deepakcs> saggi, right, thats what i also see.. just wanted= to<br> > confirm once with you, before i sent mail to ovirt folks<br> ><br> > ------------------------------------------------------------------= ---------------------------------------------------<br> ><br> ><br> > Can someone help provide any clues on what might be the issue here= ?<br> > Because VDSM doesn't see vfs_type, the connectStorageServer fails = and<br> > hence new SD cannot be created !<br> ><br> > thanx,<br> > deepak<br> ><br> ><br> ><br> ><br> ><br> ><br> > _______________________________________________<br> > Engine-devel mailing list<br> > Engine-devel@ovirt.org<br> > </font></tt><tt><font size=3D"2"><a href=3D"http://lists.ovirt.org= /mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo= /engine-devel</a></font></tt><tt><font size=3D"2"><br> <br> <br> </font></tt><br> </body></html>= --1__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C-- --0__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=08BBF1A0DF870F1C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C--
participants (3)
-
Deepak C Shetty -
Mark Wu -
Sharad Mishra