I don't think this issue is valid. virt-who behaves differently for remote libvirt connection, it behaves like with ESX and reports remote host with its guests using hypervisorCheckIn API call.

For local libvirt connection, the subscription-manager sends the hostname. For remote libvirt connection, virt-who gets the hostname from libvirt. This might cause different behaviour.

I don't see this as a bug, one host should be monitored using both local and remote libvirt mode. Do you agree?

Radek,I agree with you.However,remote libvirt mode hasn't support reporting hostname. Therefore, I use this bug to track "support for hypervisor_id to the remote libvirt mode", is that acceptable? Thanks.


(In reply to Radek Novacek from comment #1)
> I don't think this issue is valid. virt-who behaves differently for remote
> libvirt connection, it behaves like with ESX and reports remote host with
> its guests using hypervisorCheckIn API call.
> 
> For local libvirt connection, the subscription-manager sends the hostname.
> For remote libvirt connection, virt-who gets the hostname from libvirt. This
> might cause different behaviour.
> 
> I don't see this as a bug, one host should be monitored using both local and
> remote libvirt mode. Do you agree?

Yes, I'll add support for hypervisor_id to the remote libvirt backend.

Fixed in virt-who-0.14-3.el7.

Verified it on virt-who-0.14-3.el7.noarch since virt-who can report hostname after configure "hypervisor_id=hostname" when it run at remote libvirtd mode

Verified version
virt-who-0.14-3.el7.noarch
subscription-manager-1.15.9-2.el7.x86_64
python-rhsm-1.15.4-2.el7.x86_64
Satellite 6.1.0-20150731.0

Verified process:
1. Register system to Satellite server
[root@hp-z220-08 ~]# subscription-manager register --username=admin --password=admin
2. Configure virt-who run at remote libvirt mode, and configure send hostname instead of hostuuid
[root@hp-z220-08 ~]# cat /etc/virt-who.d/virt 
[test-libvirt]
type=libvirt
server=qemu+ssh://10.66.144.5/system
username=root
password=qwer1234P!
owner=ACME_Corporation
env=Library 
hypervisor_id=hostname
3. Restart virt-who service and check host/guest mapping info
[root@hp-z220-08 ~]# systemctl restart virt-who
[root@hp-z220-08 ~]# tail -f /var/log/rhsm/rhsm.log
2015-08-11 15:42:52,749 [DEBUG]  @virtwho.py:126 - Using config named 'test-libvirt'
2015-08-11 15:42:52,750 [INFO]  @virtwho.py:662 - Using configuration "test-libvirt" ("libvirt" mode)
2015-08-11 15:42:52,750 [DEBUG]  @virtwho.py:209 - Starting infinite loop with 3600 seconds interval
2015-08-11 15:42:52,785 [INFO]  @libvirtd.py:137 - Using libvirt url: qemu+ssh://root.144.5/system?no_tty=1
2015-08-11 15:42:52,972 [DEBUG]  @libvirtd.py:216 - Virtual machine found: 6.5_Server_x86_64: 8a0bc45e-5bfb-4ddd-bdcb-ed23c927f0a8
2015-08-11 15:42:52,973 [DEBUG]  @libvirtd.py:220 - Libvirt domains found: ['8a0bc45e-5bfb-4ddd-bdcb-ed23c927f0a8']
2015-08-11 15:42:52,981 [DEBUG]  @subscriptionmanager.py:112 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2015-08-11 15:42:59,904 [DEBUG]  @subscriptionmanager.py:146 - Checking if server has capability 'hypervisor_async'
2015-08-11 15:43:02,909 [DEBUG]  @subscriptionmanager.py:158 - Server does not have 'hypervisors_async' capability
2015-08-11 15:43:02,910 [INFO]  @subscriptionmanager.py:165 - Sending update in hosts-to-guests mapping: {
    "hp-z220-07.qe.lab.eng.nay.redhat.com": [
        {
            "guestId": "8a0bc45e-5bfb-4ddd-bdcb-ed23c927f0a8", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "libvirt", 
                "hypervisorType": "QEMU"
            }
        }
    ]
}
4. Open satellite web UI, check content host

Result:
virt-who send hostname instead of hostuuid to satellite, hostname can shown on the satellite web UI. Therefore, verify it

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://rhn.redhat.com/errata/RHBA-2015-2370.html