Bug 982065 - vdsClient should provide more debug info- in case of malformed XML response
vdsClient should provide more debug info- in case of malformed XML response
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.4.0
Assigned To: Piotr Kliczewski
Tareq Alayan
Depends On:
  Show dependency treegraph
Reported: 2013-07-08 00:33 EDT by Pieter Demmers
Modified: 2016-02-10 14:27 EST (History)
16 users (show)

See Also:
Fixed In Version: ovirt-3.4.0-alpha1
Doc Type: Bug Fix
Doc Text:
With this update, the vdsClient command now provides more information on errors encountered when parsing XML.
Story Points: ---
Clone Of:
Last Closed: 2014-06-09 09:25:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 972063 None None None Never
oVirt gerrit 20543 None None None Never
oVirt gerrit 21506 None None None Never

  None (edit)
Description Pieter Demmers 2013-07-08 00:33:52 EDT
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
  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
  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):


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.
Comment 1 Pieter Demmers 2013-08-06 20:35:57 EDT
Any update on this?
Comment 2 Barak 2013-08-26 09:47:08 EDT
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 ?
Comment 3 Pieter Demmers 2013-09-08 19:54:55 EDT
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.
Comment 4 Barak 2013-09-09 07:48:04 EDT
Yaniv is there an option to retrieve the malformed XML and log it ?
Comment 5 Pieter Demmers 2013-10-28 00:39:23 EDT
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.


Comment 6 Yaniv Bronhaim 2013-10-28 06:08:01 EDT
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.
Comment 7 Piotr Kliczewski 2013-11-19 03:03:12 EST
fix in commit: d7a6bd9c3d5593263692616fa0d92f047bf8db46
Comment 9 Piotr Kliczewski 2013-11-27 06:24:30 EST
fix in commit: I0c39ac88e82f2e511f0025f18586e7a251a17321 by Vinzenz
Comment 10 Tareq Alayan 2014-02-17 05:27:42 EST
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
Comment 12 Yaniv Bronhaim 2014-05-05 06:09:43 EDT
the patch [1] was merged and verified. if any other issues regarding to it appears please report or reopen the bug
Comment 13 Yaniv Bronhaim 2014-05-05 06:10:35 EDT
[1] http://gerrit.ovirt.org/#/c/21506/
Comment 14 errata-xmlrpc 2014-06-09 09:25:02 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.