Bug 1408782 - [RFE] virt-who need to make sure there is only one entry in satellite content host for the same hypervisor when configure hypervisor_id for uuid or hostname or hwuuid
Summary: [RFE] virt-who need to make sure there is only one entry in satellite content...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Candlepin
Version: 6.2.6
Hardware: x86_64
OS: Linux
low
high vote
Target Milestone: 6.5.0
Assignee: satellite6-bugs
QA Contact: jcallaha
URL:
Whiteboard:
Depends On: 1410600 1410601
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-27 07:52 UTC by Eko
Modified: 2019-11-05 22:23 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1410600 1410601 (view as bug list)
Environment:
Last Closed: 2019-05-14 12:36:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:36:28 UTC
Github candlepin candlepin pull 2035 None None None 2018-08-24 19:41:02 UTC

Description Eko 2016-12-27 07:52:50 UTC
Description of problem:
for a hypervisor mode, if configure hypervisor_id option to 3 different values(uuid, hostname, hwuuid), it will create 3 entries for the same hypervisor, it should keep an unique entry no matter what hypervisor_id configured. 


Version-Release number of selected component (if applicable):
virt-who-0.17-10.el7sat.noarch
subscription-manager-1.17.15-1.el7.x86_64
python-rhsm-1.17.9-1.el7.x86_64
Satellite-6.2.0-RHEL-7-20161219.0/

How reproducible:
always

Steps to Reproduce:
1. configure virt-who for esx mode /etc/virt-who.d/, make sure set hypervisor_id to uuid,such as:
type=esx
hypervisor_id=hostname
owner=Default_Organization
env=Library
server=10.73.130.242
username=administrator@vsphere.local
password=Welcome1!

2. restart virt-who service and check the hypervisor should be sent with uuid:
Host-to-guest mapping: {
    "ff9f4d56-f277-a538-9b51-103919b67710": [], 
    "20024d56-9faa-4267-75c9-0623ef215a23": [
        {
            "guestId": "422d664a-db1c-2773-462a-d5f308888a54", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "esx"
            }
        }, 
        {
            "guestId": "422dbb1d-c5ef-4d58-86f8-fd799f056a9b", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "esx"
            }
        }
    ]
}

3. check the content host in Satellite webUI, the hypervisors should be registered with uuid:
virt-who-ff9f4d56-f277-a538-9b51-103919b67710-1
virt-who-20024d56-9faa-4267-75c9-0623ef215a23-1

4. change the hypervisor_id to hostname, restart virt-who service, and make sure the hypervisor should be sent with hostname:
Host-to-guest mapping: {
    "bootp-73-131-189.rhts.eng.pek2.redhat.com": [], 
    "bootp-73-130-246.rhts.eng.pek2.redhat.com": [
        {
            "guestId": "422d664a-db1c-2773-462a-d5f308888a54", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "esx"
            }
        }, 
        {
            "guestId": "422dbb1d-c5ef-4d58-86f8-fd799f056a9b", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "esx"
            }
        }
    ]
}

5. check the content host in Satellite webUI, the hypervisors should be registered with hostname again, but the old uuid entries still exist.
hostname entry:
virt-who-bootp-73-130-246.rhts.eng.pek2.redhat.com-1
virt-who-bootp-73-131-189.rhts.eng.pek2.redhat.com-1

uuid entry:
virt-who-ff9f4d56-f277-a538-9b51-103919b67710-1
virt-who-20024d56-9faa-4267-75c9-0623ef215a23-1

6. change the hypervisor_id to hwuuid, restart virt-who service, and make sure the hypervisor should be sent with hwuuid:
Host-to-guest mapping: {
    "host-9": [], 
    "host-14": [
        {
            "guestId": "422d664a-db1c-2773-462a-d5f308888a54", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "esx"
            }
        }, 
        {
            "guestId": "422dbb1d-c5ef-4d58-86f8-fd799f056a9b", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "esx"
            }
        }
    ]

7. check the content host in Satellite webUI, the hypervisors should be registered with hwuuid again, but the old uuid entries still exist, now we have three different entries for the same hypervisor:
hwuuid entry:
virt-who-host-14-1
virt-who-host-9-1

hostname entry:
virt-who-bootp-73-130-246.rhts.eng.pek2.redhat.com-1
virt-who-bootp-73-131-189.rhts.eng.pek2.redhat.com-1

uuid entry:
virt-who-ff9f4d56-f277-a538-9b51-103919b67710-1
virt-who-20024d56-9faa-4267-75c9-0623ef215a23-1


Actual results:
for the same hypervisor, will create 3 different entries in Satellite WebUI

Expected results:
for the same hypervisor, no matter what I change the different hypervisor_id value, it should keep the unique entry. for example:
if hypervisor_id=uuid, send the uuid entry to satellite, delete other entries.
if hypervisor_id=hostname, send the hostname entry to satellite, delete other entries.
if hypervisor_id=hwuuid, send the hwuuid entry to satellite, delete other entries.



Additional info:

Comment 1 Justin Sherrill 2017-01-03 20:15:48 UTC
I agree 100% with this.  This behavior has caused TONs of problems for satellite including: https://bugzilla.redhat.com/show_bug.cgi?id=1372912

Sadly implementing this is not very easy and would require changes in:

virt-who
candlepin
katello

So that candlepin can track a hypervisor independent of its 'name'.  Despite the effort, i think it is worth doing.

Comment 3 Barnaby Court 2017-01-05 20:55:34 UTC
I would agree that this should be done. However, this will take significant work across Candlepin (2.0+) & virt-who and possibly Katello to support. I am using this BZ as a tracker for Satellite.

Comment 8 errata-xmlrpc 2019-05-14 12:36:19 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/RHSA-2019:1222


Note You need to log in before you can comment on or make changes to this bug.