5:45 a.m.
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(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 on
by Sharad, in Cc) as posted here...
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:maste...
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel