Created attachment 658204 [details] logs Description of problem: when I try to mount a file system with wrong params and fail in vdsm with: OSError: [Errno 2] Mount of `filer01.qa.lab.tlv.redhta.com:/Dafna5` at `/rhev/data-center/mnt/filer01.qa.lab.tlv.redhta.com:_Dafna5` does not exist engine logs shows general exception and event log shows the same: 2012-12-05 15:32:39,741 ERROR [org.ovirt.engine.core.bll.storage.POSIXFSStorageHelper] (ajp-/127.0.0.1:8702-5) [57581514] The connection with details filer01.qa.lab.tlv.redhta.com:/Dafna5 failed because of error code 100 and error message is: general exception The error code for connection filer01.qa.lab.tlv.redhta.com:/Dafna5 returned by VDSM was following General Exception Version-Release number of selected component (if applicable): si24.5 How reproducible: 100% Steps to Reproduce: 1. try to connect to a nfs directory that does not exist. 2. 3. Actual results: The error code for connection filer01.qa.lab.tlv.redhta.com:/Dafna5 returned by VDSM was following General Exception Expected results: if we cannot specify exactly why we failed we should put a more human readable error in event log. Additional info: logs
Seems like an error translation issue in StorageHelperBase (PosixStorageHelper extends it but does not override the relevant methods). regarldess of the version this is aimed at, it seems like an easy fix. Devel-acking.
issue is that vdsm is propagating a general exception. Need to fix in vdsm side. getRecord (in mount.py) is throwing an OSError raise OSError(errno.ENOENT, "Mount of `%s` at `%s` does not exist" % (self.fs_spec, self.fs_file)) But _translateConnectionError (in hsm.py) is expecting a MountError if isinstance(e, mount.MountError):
*** Bug 893383 has been marked as a duplicate of this bug. ***
Fixed according to Ayal's comment. http://gerrit.ovirt.org/#/c/10966 Change-Id: I0f36b3ea18690d7cf53439e5a0342b1495f4f181 Now the error code is 477, and Error message in the engine: The connection with details server.example.com:/export/VMs failed because of error code 477 and error message is: problem while trying to mount target
Duplicate of Bug 883879?
(In reply to comment #2) > issue is that vdsm is propagating a general exception. > Need to fix in vdsm side. > getRecord (in mount.py) is throwing an OSError > raise OSError(errno.ENOENT, > "Mount of `%s` at `%s` does not exist" % > (self.fs_spec, self.fs_file)) > But _translateConnectionError (in hsm.py) is expecting a MountError > if isinstance(e, mount.MountError): This trace is an artefact of any fail in the mount raising OSError. In order to understand the real issue, patch: http://gerrit.ovirt.org/12042 (among others) should be applied. Example: Thread-2351::DEBUG::2013-03-17 03:02:48,704::misc::85::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo -n /bin/mount -t glusterfs filer03.qa.lab.tlv.redhat.com:/DORON1 /rhev/data-center/mnt/filer03.qa.lab.tlv.redhat.com:_DORON1' (cwd None) Thread-2351::ERROR::2013-03-17 03:02:48,798::hsm::2299::Storage.HSM::(connectStorageServer) Could not connect to storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2296, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 219, in connect fileSD.validateDirAccess(self.getMountObj().getRecord().fs_file) File "/usr/share/vdsm/storage/mount.py", line 271, in getRecord (self.fs_spec, self.fs_file)) OSError: [Errno 2] Mount of `filer03.qa.lab.tlv.redhat.com:/DORON1` at `/rhev/data-center/mnt/filer03.qa.lab.tlv.redhat.com:_DORON1` does not exist When the real issue is(with a patch in the spirit of 12042): Thread-33::ERROR::2013-03-17 03:23:45,802::storageServer::212::StorageServer.MountConnection::(connect) Mount failed: (1, 'Mount failed. Please check the log file for more details.\n;/sbin/mount.glusterfs: line 130: /usr/sbin/glusterfs: Permission denied\n') Traceback (most recent call last): File "/usr/share/vdsm/storage/storageServer.py", line 210, in connect self._mount.mount(self.options, self._vfsType) File "/usr/share/vdsm/storage/mount.py", line 222, in mount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 238, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (1, 'Mount failed. Please check the log file for more details.\n;/sbin/mount.glusterfs: line 130: /usr/sbin/glusterfs: Permission denied\n')
MountError was caught and swallowed after failed mount in storageServer.py . The OSError should not have been sent or reached to begin with.
Verified, tested on RHEVM 3.3 - IS14 environment: Host OS: RHEL 6.5 RHEVM: rhevm-3.3.0-0.21.master.el6ev.noarch PythonSDK: rhevm-sdk-python-3.3.0.13-1.el6ev.noarch VDSM: vdsm-4.12.0-127.gitedb88bf.el6ev.x86_64 LIBVIRT: libvirt-0.10.2-23.el6.x86_64 QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.401.el6.x86_64 SANLOCK: sanlock-2.8-1.el6.x86_64
*** Bug 949292 has been marked as a duplicate of this bug. ***
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0040.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days