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 1314902 - 2 virt-who reporting on the same hypervisor using local libvirt and remote libvirt methods creates duplicate systems
Summary: 2 virt-who reporting on the same hypervisor using local libvirt and remote l...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-who
Version: 6.8
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Chris Snyder
QA Contact: gaoshang
URL:
Whiteboard:
Depends On:
Blocks: 1227986
TreeView+ depends on / blocked
 
Reported: 2016-03-04 19:50 UTC by Barnaby Court
Modified: 2018-06-29 12:31 UTC (History)
8 users (show)

Fixed In Version: candlepin-2.5.5-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-29 12:31:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshot for Satellite (274.61 KB, application/x-bzip)
2018-05-28 05:46 UTC, yuefliu 		no flags Details
Screenshot for Stage Candlepin (418.12 KB, application/x-bzip)
2018-05-28 05:46 UTC, yuefliu 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1410601 0 medium CLOSED [RFE] virt-who need to make sure there is only one entry in satellite content host for the same hypervisor when configu... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1566000 0 high CLOSED KVM hypervisor profile does not contain guests running on it in the webui and creates duplicate profile with virt-who-* ... 2023-09-15 00:07:28 UTC
Red Hat Bugzilla 1576110 0 high CLOSED Org admins not able to view system 2021-09-09 13:59:11 UTC

Internal Links: 1410601 1566000 1576110

Description Barnaby Court 2016-03-04 19:50:19 UTC 
Description of problem:
Use two virt-who to monitor the same host, it will generate two kinds of hostnames. Firstly,when virt-who run at local libvirt mode, it will send the local hostname to SAM. However, if use another virt-who running at remote libvirt to monitor the previous host, it will send the hypervisor uuid to SAM. Therefore, you will see the same host with two different names on SAM/Satellite WebUI

Version-Release number of selected component (if applicable):
virt-who-0.12-8.el6.noarch
subscription-manager-1.14.6-1.el6.x86_64
python-rhsm-1.14.2-1.el6.x86_64
katello-headpin-1.4.3.28-1.el6sam_splice.noarch
candlepin-0.9.6.5-1.el6sam.noarch

How reproducible:
Always

Steps to Reproduce:
1.In the host1, configure virt-who run at libvirt mode,restart virt-who service
[root@hp-z220-05 rhsm]# cat /etc/sysconfig/virt-who
VIRTWHO_BACKGROUND=1
VIRTWHO_DEBUG=1
VIRTWHO_INTERVAL=3600
[root@hp-z220-05 rhsm]# tail -f /var/log/rhsm/rhsm.log
[root@hp-z220-05 rhsm]# service virt-who restart
2. check the host/guest association info in the /var/log/rhsm/rhsm.log
2015-06-04 10:10:41,478 [INFO]  @subscriptionmanager.py:116 - Sending domain info: [{'guestId': '137a41f8-a6e1-9ffe-a537-656d6dd1e8c5', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5},]
2015-06-04 10:10:42,141 [INFO]  @virtwho.py:129 - virt-who guest list update successful
3. Register the guest to SAM/Satellite
4. Check the SAM/Satellite webUI, it will show guest's host is "host1name"
5. In the host2, configure virt-who run at remote libvirt mode to monitor host1, restart virt-who service
VIRTWHO_BACKGROUND=1
VIRTWHO_DEBUG=1
VIRTWHO_INTERVAL=3600
VIRTWHO_LIBVIRT=1
VIRTWHO_LIBVIRT_OWNER=ACME_Corporation
VIRTWHO_LIBVIRT_ENV=Library
VIRTWHO_LIBVIRT_SERVER=qemu+ssh://10.66.144.3/system
VIRTWHO_LIBVIRT_USERNAME=root
VIRTWHO_LIBVIRT_PASSWORD=
6. Check the host/guest association info in the /var/log/rhsm/rhsm.log
2015-06-04 10:20:26,379 [INFO]  @subscriptionmanager.py:123 - Sending update in hosts-to-guests mapping: {'003ac27c-ed28-e211-8973-10604b5b2b19': [{'guestId': '3394b8fa-a27b-43e0-fe39-82c587a80acd', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': '69b59f9e-3e09-d8de-ac7e-c35c6e62f292', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': '538cde5f-936e-9ca0-58ee-7528bbf86c2b', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': '137a41f8-a6e1-9ffe-a537-656d6dd1e8c5', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}, {'guestId': '3c431b66-fbab-9cce-be3c-bc15ab2adf84', 'attributes': {'active': 0, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 5}]}
7. In the SAM/Satellite webUI, Check the guest's host


Actual results:
After step6, it will generate a hypervisor uuid "003ac27c-ed28-e211-8973-10604b5b2b19"
After step7, In the SAM/Satellite WebUI, it will generate a new host "003ac27c-ed28-e211-8973-10604b5b2b19".Meanwhile, guest's host has been modified from "host1name" to "003ac27c-ed28-e211-8973-10604b5b2b19"

Expected results:
As virt-who is used to monitor the same machine, Whatever mode it is running, it should send the same hostname to SAM/Satellite. it shouldn't generate a new hypervisor uuid when virt-who run at remote libvirt mode.

Additional info:
Comment 1 Chris Snyder 2016-03-17 18:56:47 UTC 
The cause of this issue is that when virt-who reports on a local system (in libvirt mode) the information gathered about guests running on the system is reported to candlepin through the use of a PUT to /consumers/<consumer_uuid> (The updateConsumer method in ConsumerResource.java and the updateConsumer method in python-rhsm/connection.py). There is no hypervisor id reported by virt-who in this instance (although the updateConsumer method of connection.py supports it).

When virt-who reports on a remote system (still operating in libvirt mode) the information it gathers is nearly identical except that the remote system's uuid is gathered and reported as the hypervisor id. This information is passed through to an entirely different endpoint in candlepin (the method is POST /hypervisors/<owner> which maps to HypervisorUpdate() (or HypervisorUpdateAsync() depending on what the content-type header is)).

The HypervisorUpdate* methods look for existing consumers for a given hypervisor by looking for consumers with a hypervisor Id matching those in the report it is sent. By default, a consumer is created if one is not found. If guestIds are reported to have been previously attached to a consumer that does not have the given hypervisorId (in the report currently being processed) they are removed from that consumer.

In the case described above candlepin does not have the necessary information to make the connection between the locally reported consumer and the one reported remotely, consequently a new one is created (without the hostname, as that info had not been used to create the new hypervisor consumer), and the guest ids are removed from the first one.

In my opinion the solution to this bug would be for virt-who to report the hypervisorId in either case (both local and remote libvirt modes).
Comment 4 Mike McCune 2016-03-28 22:26:18 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 5 Barnaby Court 2016-06-14 14:24:23 UTC 
Fixed in tag virt-who-0.17-1
Comment 9 Jan Kurik 2017-12-06 10:54:44 UTC 
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/
Comment 15 yuefliu 2018-05-28 05:46:24 UTC 
Created attachment 1442703 [details]
Screenshot for Satellite
Comment 16 yuefliu 2018-05-28 05:46:56 UTC 
Created attachment 1442704 [details]
Screenshot for Stage Candlepin
Comment 17 William Poteat 2018-05-30 14:34:33 UTC 
Revert back to new. Will be part of larger solution.
Note You need to log in before you can comment on or make changes to this bug.