3 identical nodes with zfs+glusterfs as ovirt hosts. If I change the mount option of the storage to: backup-volfile-servers=10.10.10.44:10.10.10.42:10.10.10.41,transport=rdma the storage doesnot come up. apparently the storage is mounted correctly: root@clei21 ~]# df| grep glu 10.10.10.41:/GluReplica.rdma 3770658816 407789568 3362869248 11% /rhev/data-center/mnt/glusterSD/10.10.10.41:_GluReplica It looks that vdsm checks are not able to detect if storage mounted or not The log error stating: 2017-03-03 13:43:14,733 ERROR (jsonrpc/5) [storage.HSM] Could not connect to storageServer (hsm:2391) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2388, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 167, in connect self.getMountObj().getRecord().fs_file) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 237, in getRecord (self.fs_spec, self.fs_file)) OSError: [Errno 2] Mount of `10.10.10.41:/GluReplica` at `/rhev/data-center/mnt/glusterSD/10.10.10.41:_GluReplica` does not exist 2017-03-03 13:43:14,734 INFO (jsonrpc/5) [dispatcher] Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 100, 'id': u'4b2ea911-ef35-4de0-bd11-c4753e6048d8'}]} (logUtils:52)
This looks like a gluster bug, not vdsm bug. Sahina, can you get someone from gluster to explain why the mount fs_spec is modified? this would break any client trying to check if a mount exists.
Rafi, can you please respond?
gluster maintain separate volfile for rdma and tcp. But it doesn't had enough argument to specify the transport during the rpc request. Hence this was an hack introduced. I agree that we should fix this issue. I will take that up and see how we can fix this issue. We may need to wait for another major release to get the fix if it involves any change in rpc req.
Tested with RHV 4.2.3 with IB client and IB servers. 1. Created gluster volume with transport=rdma 2. Created a storage domain with additional mount options mentioned as transport=rdma 3. The storage domain comes up operational
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.