Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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 1779812

Summary: Satellite is not updating the hypervisor FQDN when this changed but UUID still the same (virt-who pushing)
Product: Red Hat Satellite Reporter: Waldirio M Pinheiro <wpinheir>
Component: Subscriptions - virt-whoAssignee: Barnaby Court <bcourt>
Status: CLOSED CURRENTRELEASE QA Contact: Kunxin Huang <kuhuang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.6.0CC: csnyder, jsherril, jturel, mhulan, wpoteat, yuefliu
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-10 21:06:47 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:

Description Waldirio M Pinheiro 2019-12-04 19:10:12 UTC
Description of problem:
The customer has changed some hypervisors fqdn and this was not reflected to Satellite webUI. Some hypervisors still missing and the customer is complaning about that.

Version-Release number of selected component (if applicable):
6.6.z

How reproducible:
100% on the customer environment, didn't try locally.

Steps to Reproduce:
1. Configure virt-who (the info will be on satellite webUI)
2. Renaming the hypervisor FQDN
3. virt-who pushing again the information

Actual results:
Some machines from the customer virtualization environment didn't appear on Satellite webUI

Expected results:
See all hypervisors form the customer virtualization environment

Additional info:

Comment 10 William Poteat 2019-12-17 14:53:28 UTC
Is the FQDN getting passed in as the field "name" in the json from virt-who?

If so this is a bug in Candlepin where the "name" field is not updated on the hypervisor from the hypervisor report.

Comment 11 Waldirio M Pinheiro 2019-12-17 18:05:54 UTC
Hello William

Yea, the new name is there.

I did this code [1] just to check and let us know. Let's check the output below
---
# ./compare_hypers.sh                               
###################################
Hypervisors on Satellite DB ......: 6
Hypervisors on vCenter Inventory .: 5
###################################

DIFFERENT INFO
SAT FQDN .......: server.domain.local
VCENTER FQDN ...: XPTO.domain.local
SAT UUID .......: 30393137-3436-584d-5136-303730304747
VCENTER UUID ...: 30393137-3436-584d-5136-303730304747



If no output above, everything is fine (UUID and FQDN matching).
---

Note., the UUID still the same, "SAT FQDN" is the name stored in DB and "VCENTER FQDN" is the info coming from vcenter/virt-who. In order to fix that, just removing the "SAT FQDN" via Satellite webUI and running once virt-who is enough, the new hypervisor will be displayed correctly in Satellite webUI.


[1]. https://github.com/waldirio/compare_hypervisors

Comment 12 William Poteat 2020-01-06 20:35:29 UTC
Please attach the json block that virt who sends when reporting on this system.

Comment 15 Waldirio M Pinheiro 2020-01-10 18:51:14 UTC
Hello all

Below the steps to reproduce the same behavior


// Installed packages
---
# rpm -qa | grep -E '(virt-who|candlepin)'
candlepin-2.6.9-1.el7sat.noarch
candlepin-selinux-2.6.9-1.el7sat.noarch
virt-who-0.24.7-1.el7.noarch
---

1. First, let's do a configuration to our vCenter and generate a JSON file with the command below:
	---
	# virt-who -op >/etc/virt-who.d/json/file.json
	---

2. Now, let's create the virt-who conf file
	---
	# cat /etc/virt-who.d/fake.conf 
	[fake-virt]
	type=fake
	file=/etc/virt-who.d/json/file.json

	hypervisor_id=hostname
	owner=ACME
	env=Library
	rhsm_hostname=wallsat66.usersys.redhat.com
	rhsm_username=virt_who_reporter_1
	rhsm_encrypted_password=9df8a042a45a49f6d70c223dfa520039f3955370d9346353d22d7fd799229e15
	rhsm_prefix=/rhsm
	---

3. Let's push our configuration using "virt-who -od", then we can see
	---
	{
		"hypervisors": [
			{
				"hypervisorId": {
					"hypervisorId": "esxi4.lab.eng.rdu2.redhat.com"
				}, 
				"name": "esxi4.lab.eng.rdu2.redhat.com", 
				"guestIds": [
					{
						"guestId": "420d2a4a-e2ed-86ea-e52d-8f3deeee3078", 
						"state": 5, 
						"attributes": {
							"active": 0, 
							"virtWhoType": "esx"
						}
					}, 
	...
				"facts": {
					"hypervisor.type": "VMware ESXi", 
					"dmi.system.uuid": "4c4c4544-0031-4310-804c-b8c04f435931", 
					"cpu.cpu_socket(s)": "4", 
					"hypervisor.cluster": "vMotion-Cluster", 
					"hypervisor.version": "6.7.0"
				}
			}, 
	---

And on Satellite Server
	---
	# hammer host list --search 'name ~ virt-who*'
	---|------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	ID | NAME                                     | OPERATING SYSTEM | HOST GROUP | IP | MAC | GLOBAL STATUS | CONTENT VIEW | LIFECYCLE ENVIRONMENT
	---|------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	10 | virt-who-esxi1.lab.eng.rdu2.redhat.com-1 |                  |            |    |     | Warning       |              |                      
	9  | virt-who-esxi2.lab.eng.rdu2.redhat.com-1 |                  |            |    |     | Warning       |              |                      
	8  | virt-who-esxi4.lab.eng.rdu2.redhat.com-1 |                  |            |    |     | Warning       |              |                      
	11 | virt-who-esxi5.lab.eng.rdu2.redhat.com-1 |                  |            |    |     | Warning       |              |                      
	---|------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	---

4. Let's change the JSON file content from "esxi4.lab.eng.rdu2.redhat.com" to "newserver.lab.eng.rdu2.redhat.com"
	---
	# sed -i 's/esxi4/newserver/g' /etc/virt-who.d/json/file.json
	---

5. Let's push once our configuration using "virt-who -od", then we can see
	---
	{
		"hypervisors": [
			{
				"hypervisorId": {
					"hypervisorId": "newserver.lab.eng.rdu2.redhat.com"
				}, 
				"name": "newserver.lab.eng.rdu2.redhat.com", 
				"guestIds": [
					{
						"guestId": "420d2a4a-e2ed-86ea-e52d-8f3deeee3078", 
						"state": 5, 
						"attributes": {
							"active": 0, 
							"virtWhoType": "esx"
						}
					},
	...
				"facts": {
					"hypervisor.type": "VMware ESXi", 
					"dmi.system.uuid": "4c4c4544-0031-4310-804c-b8c04f435931", 
					"hypervisor.version": "6.7.0", 
					"hypervisor.cluster": "vMotion-Cluster", 
					"cpu.cpu_socket(s)": "4"
				}
			}, 
	---

	Also, in CP logs
	---
	# tailf /var/log/candlepin/candlepin.log| grep -B1 Updated

	2020-01-10 18:14:03,936 [thread=QuartzScheduler_Worker-4] [job=hypervisor_update_29c7d859-776c-444c-9b0c-18b942ec48d2, org=ACME, csid=] INFO  org.candlepin.pinsetter.tasks.HypervisorUpdateJob - Summary for report from null by principal {"type":"trusteduser","name":"foreman_admin"}
	 Created: 0, Updated: 1, Unchanged: 3, Failed: 0
	---

6. Doing the hammer query once we can see the value was updated correctly
	---
	# hammer host list --search 'name ~ virt-who*'
	---|----------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	ID | NAME                                         | OPERATING SYSTEM | HOST GROUP | IP | MAC | GLOBAL STATUS | CONTENT VIEW | LIFECYCLE ENVIRONMENT
	---|----------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	10 | virt-who-esxi1.lab.eng.rdu2.redhat.com-1     |                  |            |    |     | Warning       |              |                      
	9  | virt-who-esxi2.lab.eng.rdu2.redhat.com-1     |                  |            |    |     | Warning       |              |                      
	11 | virt-who-esxi5.lab.eng.rdu2.redhat.com-1     |                  |            |    |     | Warning       |              |                      
	8  | virt-who-newserver.lab.eng.rdu2.redhat.com-1 |                  |            |    |     | Warning       |              |                      
	---|----------------------------------------------|------------------|------------|----|-----|---------------|--------------|----------------------
	---


At this moment, I'm doing the similar steps as above, however, keeping the process running "systemctl restart virt-who" and changing the json file "/etc/virt-who.d/json/file.json", however, no success.


That said, this is the expected behavior and it's working as expected.

I'll check with the customer if the JSON generated is not bringing the correct information (new FQDN on the correct fields).

I'll keep you all in touch.

Comment 16 Waldirio M Pinheiro 2020-01-10 20:35:37 UTC
Hello

Just to complement, running as a service, the update was concluded with no issues and as expected.

I believe we can archive this one.

Thank you all.