Description of problem: When the vdsClient command fails it gives little information on why it fails (e.g. if it has an issue with a vm): # vdsClient -s 0 list table Traceback (most recent call last): File "/usr/share/vdsm/vdsClient.py", line 2411, in <module> code, message = commands[command][0](commandArgs) File "/usr/share/vdsm/vdsClient.py", line 280, in do_list response = self.s.getAllVmStats() File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request return self._parse_response(h.getfile(), sock) File "/usr/lib64/python2.6/xmlrpclib.py", line 1387, in _parse_response p.feed(response) File "/usr/lib64/python2.6/xmlrpclib.py", line 601, in feed self._parser.Parse(data, 0) ExpatError: not well-formed (invalid token): line Version-Release number of selected component (if applicable): RFE: Either the command runs per client and outputs the result (rather than trying to collecting all data and barfing if it has an issue) and/or provide an error indicating which vm is the cause of the issue.
Any update on this?
How can we reproduce it ? The error above "not well-formed (invalid token): line" meaning that the response from vdsm service got bad XML in response (probably some parameter had bad characters in it ???). If we could understand the root cause for the malformed XML we can fix it, Do you have any idea how we can reproduce it ? Anyway can we get the vdsm log ?
This was caused by the issue mentioned in BZ 983402 - I think it does not really matter what causes it - what the customer is asking is, if there is an issue with one VM, it should not cause the whole command to fail - or it should at least tell you which VM caused the error. I am not sure that we will be able to get the vdsm log as the customer has since upgraded and is no longer getting the issue.
Yaniv is there an option to retrieve the malformed XML and log it ?
Update from customer (Colin Coe from Horizon Power case: 00900660) Hi guys Not really sure what I can add. It seemed that the client agent was sending junk and it really confused vdsClient, particularly when doing the 'list table' If there was junk coming from the client agent, 'vdsClient -s benvir1p list table' would give a trackback with no usable info. This seemed to me that it collected and formatted the data then when it had everything prints it out. This meant that users got nothing. If the data was collected and printed as it went, then at least it would be clear which VM was causing the problem. Thanks CC
I agree with Pieter, the suggested patch should do the work of printing the malformed xml part and it will provide the needed information to the distinguish the specific problematic vm info. Please review.
fix in commit: d7a6bd9c3d5593263692616fa0d92f047bf8db46
fix in commit: I0c39ac88e82f2e511f0025f18586e7a251a17321 by Vinzenz
couldn't reproduce. Move to verify. tested on ovirt-engine-3.4.0-0.7.beta2.el6.noarch / vdsm-4.14.1-3.el6.x86_64
the patch [1] was merged and verified. if any other issues regarding to it appears please report or reopen the bug
[1] http://gerrit.ovirt.org/#/c/21506/
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-0504.html