Bug 1391512

Summary: virt-who fails to report VMs when VM name/description contains non-ascii characters
Product: Red Hat Enterprise Linux 6 Reporter: Michal Dekan <mdekan>
Component: virt-whoAssignee: Patrick Creech <pcreech>
Status: CLOSED ERRATA QA Contact: Eko <hsun>
Severity: urgent Docs Contact:
Priority: high    
Version: 6.8CC: ajoseph, bji, csnyder, ekin.meroglu, khowell, ktordeur, pcreech, rbalakri, rdini, rjerrido, wpoteat, yqu, yuefliu
Target Milestone: rcKeywords: Triaged
Target Release: 6.10   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1437228 1439279 (view as bug list) Environment:
Last Closed: 2018-06-19 05:21:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1437228, 1461138, 1506745    

Comment 10 yuefliu 2017-03-01 09:27:22 UTC
No this bug with ESX and Hyper-V mode, but it reproduced on Xen mode.

After name the guest on Xenserver with chinese words, virt-who will fail to send mapping info with below log:

*****rhsm.log
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/virtwho/virt/virt.py", line 371, in run
    self._run()
  File "/usr/lib/python2.6/site-packages/virtwho/virt/xen/xen.py", line 188, in _run
    assoc = self.getHostGuestMapping()
  File "/usr/lib/python2.6/site-packages/virtwho/virt/xen/xen.py", line 81, in getHostGuestMapping
    vm = self.session.xenapi.VM.get_record(resident)
  File "/usr/lib/python2.6/site-packages/virtwho/virt/xen/XenAPI.py", line 227, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.6/site-packages/virtwho/virt/xen/XenAPI.py", line 132, in xenapi_request
    result = _parse_result(getattr(self, methodname)(*full_params))
  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/lib/python2.6/site-packages/virtwho/util.py", line 45, in request
    return self.parse_response(resp)
  File "/usr/lib/python2.6/site-packages/virtwho/util.py", line 52, in parse_response
    p.feed(resp.text)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 601, in feed
    self._parser.Parse(data, 0)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 657-662: ordinal not in range(128)
2017-03-01 17:01:36,678 [virtwho.sate-xen INFO] Xen-1(12637):MainThread @virt.py:run:391 - Waiting 60 seconds before retrying backend 'sate-xen'

Comment 11 Chris Snyder 2017-03-09 14:47:17 UTC
I think this bug is related to https://bugzilla.redhat.com/show_bug.cgi?id=1388577

I will check with Patrick to see if the fix for that bug (which has been merged) will also solve this issue.

Comment 12 Chris Snyder 2017-03-09 18:45:15 UTC
Patrick has looked into this issue and believes it to be similar to the bug mentioned in comment 11.

Assigning to him.

Comment 13 Yunyun Qu 2017-03-14 07:44:33 UTC
Any updates till now? Have we confirmed it's the same bug as Patrick handled before?

Comment 15 Yunyun Qu 2017-03-15 13:34:41 UTC
Hi Chris

Many thanks for bringing this good news!

Customer is using satellite on RHEL7.3, while virt-who is installed on RHEL6.8. It's suggested customer to use virt-who on RHEL7.3, and they agreed. 

So if we could include this fix in RHEL7.3.z, that would be really helpful for customers. 

What's you opinion?

Comment 16 Yunyun Qu 2017-03-15 13:35:55 UTC
Hi Chris

Many thanks for bringing this good news!

Customer is using satellite on RHEL7.3, while virt-who is installed on RHEL6.8. It's suggested customer to use virt-who on RHEL7.3, and they agreed. 

So if we could include this fix in RHEL7.3.z, that would be really helpful for customers. 

What's you opinion?

Comment 27 errata-xmlrpc 2018-06-19 05:21:42 UTC
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.

https://access.redhat.com/errata/RHBA-2018:1915