Bug 1779812 - Satellite is not updating the hypervisor FQDN when this changed but UUID still the same (virt-who pushing)
Summary: Satellite is not updating the hypervisor FQDN when this changed but UUID stil...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscriptions - virt-who
Version: 6.6.0
Hardware: All
OS: All
unspecified
high
Target Milestone: Unspecified
Assignee: Barnaby Court
QA Contact: Kunxin Huang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-04 19:10 UTC by Waldirio M Pinheiro
Modified: 2023-03-24 16:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-10 21:06:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github waldirio/compare_hypervisors 0 None None None 2020-07-27 10:04:58 UTC

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.


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