RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 1506745
TreeView+ depends on / blocked
 
Reported: 2016-07-19 05:59 UTC by Sandeep
Modified: 2019-12-16 06:08 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
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github virt-who virt-who pull 76 0 None closed 1357761: Do not check passwords to be in latin1 encoding 2020-10-21 04:05:51 UTC
Red Hat Bugzilla 1492074 0 medium CLOSED Problem with virt-who using Unicode characters in a hypervisor's account password 2021-09-09 12:36:35 UTC
Red Hat Product Errata RHBA-2018:1915 0 None None None 2018-06-19 05:23:02 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.