[Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case

Tue Mar 19 02:45:24 UTC 2013

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 at 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 at linux.vnet.ibm.com>
> Organization: 	IBM India Pvt. Ltd.
> To: 	users at ovirt.org <users at ovirt.org>, Sharad Mishra
> <snmishra at 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+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.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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel