Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357761 - Problem with virt-who using Unicode characters in a hypervisor's account password?
Summary: Problem with virt-who using Unicode characters in a hypervisor's account pass...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-who
Version: 6.7
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Jiri Hnidek
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks: 1461138 1503271
TreeView+ depends on / blocked
 
Reported: 2016-07-19 05:59 UTC by Sandeep
Modified: 2018-06-19 05:23 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1503271 (view as bug list)
Environment:
Last Closed: 2018-06-19 05:21:42 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1915 None None None 2018-06-19 05:23:02 UTC
Red Hat Bugzilla 1492074 None CLOSED Problem with virt-who using Unicode characters in a hypervisor's account password 2019-04-10 04:25:15 UTC
Github virt-who virt-who pull 76 None None None 2017-06-12 19:04:26 UTC

Internal Links: 1492074

Description Sandeep 2016-07-19 05:59:15 UTC
Description of problem:
Problem with virt-who using Unicode characters in a hypervisor's account password

When using Unicode characters in the virt-who configuration's ESX user password, virt-who bails out without any clear error message.
In our particular case, we were using a Euro symbol in the password.
After removing the Unicode character, virt-who started to work as expected.

Error:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: ordinal not in range(128)
--------------------
Here is the relevant config in /etc/sysconfig/virtwho:
    VIRTWHO_BACKGROUND=1
    VIRTWHO_DEBUG=1
    VIRTWHO_ESX=1
    VIRTWHO_ESX_OWNER=0000000  (anonymized)
    VIRTWHO_ESX_ENV=Library
    VIRTWHO_ESX_SERVER=myvcenter.mydomain.local
    VIRTWHO_ESX_USERNAME=service_account_id@MSDOMAIN
    VIRTWHO_ESX_PASSWORD=1€345678
--------------------

Consulted symgmt list and as per reproducer from Rich Jerrido Euro symbol in the password however, it went through without any issue. However, Same procedure is not working for customer.

As per Paul Wayper informed the customer to do the configuration on /etc/virt-who.d but it gacve below error:

----------------
[root@myhost sysconfig]# service virt-who start
Starting virt-who: 2016-04-20 14:45:13,610 INFO: Using configuration 
"x-farm" ("esx" mode)
2016-04-20 14:45:20,487 ERROR: Virt backend 'x-farm' fails with error: 
Reporting of hypervisor MY-HYPER-VISOR is not implemented in esx backend
2016-04-20 14:45:20,488 INFO: Waiting 3600 seconds before retrying backend 
'x-farm'
^C                                                         [FAILED]
==========================
After fixing the first line from [x-farm] to [esx-farm].
---------------
# service virt-who start
Starting virt-who: 2016-05-06 11:35:54,884 INFO: Using configuration "esx-farm" ("esx" mode)
2016-05-06 11:36:01,273 ERROR: Virt backend 'esx-farm' fails with error: Reporting of hypervisor bsaz-zhru-pvh03.belsoftnet.local is not implemented in esx backend
2016-05-06 11:36:01,274 INFO: Waiting 3600 seconds before retrying backend 'esx-farm'
---------------

Please help me on this?

Comment 2 Radek Novacek 2016-07-21 07:21:30 UTC
The configuration in /etc/virt-who.d/ should work with unicode characters, but make sure the file is in UTF-8 encoding (e.g. using `file` command).

The error "Reporting of hypervisor bsaz-zhru-pvh03.belsoftnet.local is not implemented in esx backend" is caused by invalid option in the `hypervisor_id` config. One of "uuid", "hwuuid", or "hostname" literals should be used instead of putting the hostname there directly.

Let me know if this solves the issue.

Comment 3 Sandeep 2016-07-21 07:54:17 UTC
Thank you for your update.

I will check the same with the customer and get back to you.

Comment 5 Radek Novacek 2016-10-06 08:24:00 UTC
Sandeep, do you have any update from the customer?

Comment 8 Chris Snyder 2017-05-11 18:36:50 UTC
The behaviour appears to have changed in newer versions of virt-who. In newer versions a traceback is printed to stdout, the result of an InvalidOption exception with the message "Option 'password' is not in latin1 encoding".

I still believe this to be an issue.

As the customer issue has been closed I am clearing needinfo on Sandeep.

Comment 9 Jiri Hnidek 2017-06-12 11:59:43 UTC
I can't reproduce this bug, but I can see following message many times in output of strace command in current master branch:

stat("/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned", 0x7ffdda271bd0) = -1 ENOENT (No such file or directory)

Comment 10 Jiri Hnidek 2017-06-12 19:04:27 UTC
It is also possible to reproduce this bug, when you simply set following environment variables:

export VIRTWHO_ESX_SERVER=myvcenter.mydomain.local
export VIRTWHO_ESX=1
export VIRTWHO_ESX_ENV=Library
export VIRTWHO_ESX_OWNER=0000000
export VIRTWHO_ESX_USERNAME=service_account_id@MSDOMAIN
export VIRTWHO_ESX_PASSWORD=1€345678

Then it is possible to run virt-who from local installation using: ./virt-who -o -d, because /etc/sysconfig/virt-who is read, when virt-who is installed in system (bash script virt-who-initscript).

Comment 11 Chris Snyder 2017-06-12 19:54:16 UTC
The fix has been merged to upstream virt-who. The fix should be included in the rebase on upstream for 6.10. As such I'm moving this bug to the MODIFIED state.

Comment 22 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


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