Bug 1227986

Can you please set up 'hypervisor_id=hostname' for the second part (remote libvirt)? It might help.

But generally I don't think we need to support the case when the same system is monitored by two different virt-who methods (libvirt local and libvirt remote) as those method can differ a lot.

When set 'hypervisor_id=hostname' for remote libvirt, virt-who will generate a new host(the same hostname as before, different "Register by") to satellite. please see the screetshot in attachment.

Created attachment 1126948 [details]
same host_diff register by

This looks like bug in candlepin - it does not match the same host to itself.

OTOH I'm not sure we want to support this usecase. When user switches method how to get host/guest association (either between libvirt and remote libvirt, or vdsm and rhevm), I think it's ok to recreate the hosts.

If you think we should support this usecase, please switch this bug to candlepin for further evaluation.

Can you please attach the virt-who reports that are generated for each system.

Checked version:
virt-who-0.16-6.el6.noarch
python-rhsm-1.16.6-1.el6.x86_64
subscription-manager-1.16.8-4.el6.x86_64

Checked process:
1 Register host1 to satellite
2 On host1, run virt-who at local libvirt mode
[root@ibm-x3250m4-07 ~]# cat /etc/sysconfig/virt-who  | grep -v ^# | grep -v ^$
VIRTWHO_DEBUG=1
3 On host1, restart virt-who and check virt-who's log,it will send local host/guest mapping info to satellite
[root@ibm-x3250m4-07 ~]# service virt-who restart && tail -f /var/log/rhsm/rhsm.log 
Stopping virt-who: [  OK  ]
Starting virt-who: [  OK  ]
...........
2016-03-09 00:08:55,748 [virtwho.main INFO] MainProcess(26848):MainThread @subscriptionmanager.py:sendVirtGuests:147 - Sending update in guests lists for config "env/cmdline": 1 guests found
2016-03-09 00:08:55,748 [virtwho.main DEBUG] MainProcess(26848):MainThread @subscriptionmanager.py:sendVirtGuests:148 - Domain info: [
    {
        "guestId": "d06af74a-2372-6554-d465-a8474fda6e00", 
        "state": 5, 
        "attributes": {
            "active": 0, 
            "hypervisorVersion": "0.12.1", 
            "virtWhoType": "libvirt", 
            "hypervisorType": "QEMU"
        }
    }
]
2016-03-09 00:08:58,104 [virtwho.main DEBUG] MainProcess(26848):MainThread @virtwho.py:send_report:161 - Report for config "env/cmdline" sent
4. Go to satellite webUI, it will show host1's hostname in content-host page. registered by "Admin User" , please see the screenshot "first host.jpeg"

5. In host2: configure virt-who run at remote libvirt to monitor host1.
[root@ibm-x3250m4-08 ~]# cat /etc/virt-who.d/virt 
[t-libvirt]
type=libvirt
server=qemu+ssh://ibm-x3250m4-07.rhts.eng.bos.redhat.com/system
username=root
password=qwer1234P!
owner=ACME_Corporation
env=Library 
hypervisor_id=hostname
6 On host2, restart virt-who and check virt-who's log,it will send host1's host/guest mapping info to satellite
2016-03-09 01:15:38,036 [virtwho.main DEBUG] MainProcess(25609):MainThread @subscriptionmanager.py:hypervisorCheckIn:186 - Host-to-guest mapping: {
    "ibm-x3250m4-07.rhts.eng.bos.redhat.com": [
        {
            "guestId": "d06af74a-2372-6554-d465-a8474fda6e00", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "hypervisorVersion": "0.12.1", 
                "virtWhoType": "libvirt", 
                "hypervisorType": "QEMU"
            }
        }
    ]
}
7. Go to satellite webUI, it will show a new host1's hostname in content-host page. but registered by "683a8bb9-0f1a-464d-88a1-7dd309ab9af0", please see the screenshot "second host.jpeg"

Result:
Although virt-who report the same host's mapping info to satellite, it will show two same hostname in content host page.

Expected result:
Since virt-who report the same host's mapping info to satellite, it should show the same hostname in content host page.

Created attachment 1134393 [details]
first host

Created attachment 1134394 [details]
second host

Fixed upstream in virt-who-0.17-1

MODIFIED

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-2016:1616