Bug 1401420

Summary: Setting hypervisor_id to hostname or hwuuid, can't show all the hypervisors mapping info
Product: Red Hat Enterprise Linux 6 Reporter: Eko <hsun>
Component: virt-whoAssignee: Jiri Hnidek <jhnidek>
Status: CLOSED ERRATA QA Contact: Eko <hsun>
Severity: medium Docs Contact:
Priority: high    
Version: 6.9CC: csnyder, hsun, jhnidek, jkurik, rbalakri, rjerrido, sgao, wpoteat, yuefliu
Target Milestone: rcKeywords: Triaged
Target Release: 6.10   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1463005 (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: 1463005    

Description Eko 2016-12-05 08:29:01 UTC
Description of problem:
I created a pool in xencenter, and add two xenservers to this pool.
if set hypervisor_id to uuid, virt-who can show these two xenservers's uuid
but, if set hypervisor_id to hostname or hwuuid, virt-who only show one xenservers's hostname or hwuuid.


Version-Release number of selected component (if applicable):
RHEL-6.9-20161201.0
virt-who-0.18-1.el6.noarch


How reproducible:
always

Steps to Reproduce:
1. create a pool in xencenter, and then add two xenservers to this pool

2. configure virt-who with hypervisor_id=uuid, restart virt-who and check the rhsm.log
[test-xen]
type=xen
server=10.73.5.210
username=root
password=red2017
owner=8046180
env=8046180
hypervisor_id=uuid


====== rhsm.log ======
2016-12-05 03:24:21,297 [virtwho.main INFO] MainProcess(23542):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Sending update in hosts-to-guests mapping for config "test-xen": 2 hypervisors and 1 guests found

2016-12-05 03:24:21,298 [virtwho.main DEBUG] MainProcess(23542):MainThread @subscriptionmanager.py:hypervisorCheckIn:196 - Host-to-guest mapping: {
    "d4a794b5-e159-47eb-9b3e-12e666ce2b0e": [], 
    "c75a0a65-1045-4f4a-987f-15fcd455533e": [
        {
            "guestId": "c092460f-9e1c-b713-fb30-3fb142430836", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }
    ]
}
2016-12-05 03:24:23,836 [virtwho.main DEBUG] MainProcess(23542):MainThread @executor.py:send_report:102 - Report for config "test-xen" sent


3. configure virt-who with hypervisor_id=hostname, restart virt-who and check the rhsm.log

========== rhsm.log,  only list one hostname =======
2016-12-05 03:25:49,053 [virtwho.main INFO] MainProcess(23579):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Sending update in hosts-to-guests mapping for config "test-xen": 2 hypervisors and 1 guests found
2016-12-05 03:25:49,054 [virtwho.main DEBUG] MainProcess(23579):MainThread @subscriptionmanager.py:hypervisorCheckIn:196 - Host-to-guest mapping: {
    "localhost": []
}
2016-12-05 03:25:50,569 [virtwho.main DEBUG] MainProcess(23579):MainThread @executor.py:send_report:102 - Report for config "test-xen" sent


4. configure virt-who with hypervisor_id=hwuuid, restart virt-who and check the rhsm.log

========== rhsm.log,  only list one hwuuid =======
2016-12-05 03:27:25,459 [virtwho.main INFO] MainProcess(23615):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Sending update in hosts-to-guests mapping for config "test-xen": 2 hypervisors and 1 guests found
2016-12-05 03:27:25,459 [virtwho.main DEBUG] MainProcess(23615):MainThread @subscriptionmanager.py:hypervisorCheckIn:196 - Host-to-guest mapping: {
    "fffa322b-0fabfbff-00000021-2c100800": []
}



Actual results:
set hypervisor_id to hostname or hwuuid, only list one xenserver info


Expected results:
it should list two xenservers info as uuid.

Additional info:

Comment 5 Chris Snyder 2017-05-11 20:47:56 UTC
I am unable to reproduce this with the xen configuration given.

Is there a test instance of xen that is always running I can use to test against for this bug and for the future.

Comment 7 Liushihui 2017-05-27 14:36:36 UTC
Reproduced it on esx+satellite6.2.10-sp2(virt-who-0.19-2.el6sat.noarch). 

the log info as the following:
2017-05-27 09:41:38,455 [virtwho.main DEBUG] MainProcess(5282):MainThread @executor.py:terminate:308 - virt-who is shutting down
2017-05-27 09:41:39,482 [virtwho.esx DEBUG] Esx-1(5288):MainThread @virt.py:run:404 - Virt backend 'esx' terminated
2017-05-27 09:41:39,487 [virtwho.main DEBUG] MainProcess(5282):MainThread @__main__.py:main:23 - virt-who terminated
2017-05-27 09:41:40,695 [virtwho.init DEBUG] MainProcess(5406):MainThread @executor.py:__init__:66 - Using config named 'esx'
2017-05-27 09:41:40,696 [virtwho.init INFO] MainProcess(5406):MainThread @main.py:main:165 - Using configuration "esx" ("esx" mode)
2017-05-27 09:41:40,696 [virtwho.init INFO] MainProcess(5406):MainThread @main.py:main:167 - Using reporter_id='esx-rhel6.9-sattool.redhat.com'
2017-05-27 09:41:40,853 [virtwho.main DEBUG] MainProcess(5412):MainThread @executor.py:run:176 - Starting infinite loop with 3600 seconds interval
2017-05-27 09:41:40,901 [virtwho.esx DEBUG] Esx-1(5418):MainThread @virt.py:run:379 - Virt backend 'esx' started
2017-05-27 09:41:40,903 [virtwho.esx DEBUG] Esx-1(5418):MainThread @esx.py:_prepare:128 - Log into ESX
2017-05-27 09:41:41,052 [virtwho.esx DEBUG] Esx-1(5418):MainThread @esx.py:_prepare:131 - Creating ESX event filter
2017-05-27 09:41:41,109 [virtwho.esx DEBUG] Esx-1(5418):MainThread @esx.py:getHostGuestMapping:266 - Host 'host-9' doesn't have hypervisor_id property
2017-05-27 09:41:41,109 [virtwho.esx DEBUG] Esx-1(5418):MainThread @esx.py:getHostGuestMapping:266 - Host 'host-17' doesn't have hypervisor_id property
2017-05-27 09:41:41,109 [virtwho.esx DEBUG] Esx-1(5418):MainThread @virt.py:enqueue:372 - Report for config "esx" gathered, putting to queue for sending
2017-05-27 09:41:41,129 [virtwho.main DEBUG] MainProcess(5412):MainThread @subscriptionmanager.py:_connect:124 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2017-05-27 09:41:41,299 [virtwho.main DEBUG] MainProcess(5412):MainThread @subscriptionmanager.py:hypervisorCheckIn:172 - Checking if server has capability 'hypervisor_async'
2017-05-27 09:41:41,473 [virtwho.main DEBUG] MainProcess(5412):MainThread @subscriptionmanager.py:hypervisorCheckIn:184 - Server does not have 'hypervisors_async' capability
2017-05-27 09:41:41,473 [virtwho.main INFO] MainProcess(5412):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Sending update in hosts-to-guests mapping for config "esx": 0 hypervisors and 0 guests found
2017-05-27 09:41:41,473 [virtwho.main DEBUG] MainProcess(5412):MainThread @subscriptionmanager.py:hypervisorCheckIn:196 - Host-to-guest mapping: {}
==========================Nothing can show====================================
2017-05-27 09:41:42,558 [virtwho.main DEBUG] MainProcess(5412):MainThread @executor.py:send_report:102 - Report for config "esx" sent

Comment 9 Jiri Hnidek 2017-06-19 12:06:21 UTC
I just noted comment in different BZ report 1415064 that hypervisor_ids are same, when hwuuid is used. Yes, I can confirm this. But when I go to man pages of virt-who-config I see folowing statement: "hwuuid is applicable to esx and rhevm only". 

Thus hypervisor_id=hwuuid should IMHO raise exception, when type is different from esx and rhevm. Other types of virtualization backend raise such exception. Xen should not be different, because we can not guarantee uniqueness of record["cpu_info"]['features'] (two hypervisors can have same type CPUs).

Comment 11 Jiri Hnidek 2017-06-22 17:16:55 UTC
*** Bug 1415064 has been marked as a duplicate of this bug. ***

Comment 12 yuefliu 2017-07-31 03:47:50 UTC
By checking with virt-who-0.20.4-1.el7sat.noarch, has no this bug. 

When run virt-who in xen mode with hypervisor_id=hwuuid, it fails with error: "Invalid option hwuuid for hypervisor_id, use one of: uuid or hostname", which error is same with libvirt and hyperv.

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