6:46 a.m.
--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(a)linux.vnet.ibm.com
To: Deepak C Shetty <deepakcs(a)linux.vnet.ibm.com>,
Cc: "engine-devel(a)ovirt.org" <engine-devel(a)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:
<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/13...
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(a)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
&lt;wudxw(a)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
&lt;deepakcs(a)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">&quot;engine-devel(a)ovirt.org&quot; <=
engine-devel(a)ovirt.org&gt;, 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
&lt;deepakcs(a)linux.vnet.ibm.com&gt;<br >
Organization: IBM India Pvt. Ltd.<br >
To: users(a)ovirt.org &lt;users(a)ovirt.org&gt;, Sharad Mishra<br > &lt;snmishra(a)us.ibm.com&gt;<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+b...
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(a)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(a)us.ibm.com
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__=08BBF1A0DF870F1C8f9e8a93df938690918c08BBF1A0DF870F1C--
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(a)linux.vnet.ibm.com
Organization: IBM India Pvt. Ltd.
To: users(a)ovirt.org <users(a)ovirt.org>, Sharad Mishra
<snmishra(a)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(a)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