Some host and guest mappings reported via virt-who do not update the Satellite

Environment

Red Hat Satellite 6

Issue

virt-who is correctly gathering host and guest mappings and updating some mappings, but not others, on the Red Hat Satellite

Resolution

None. This is behaving as designed.

Old Content Host with the same dmi.system.uuid must be removed from Red Hat Satellite before another with the same dmi.system.uuid is allowed to report.

For more KB articles/solutions related to Virt-who and Virtual Datacenter (VDC) Subscriptions Issues, please refer to the Consolidated Troubleshooting Article for Virt-who and Virtual Datacenter (VDC) Subscriptions Issues

Root Cause

Red Hat Satellite determines the uniqueness of a hypervisor based on the dmi.system.uuid.

If a physical hypervisor is reported to Satellite, and then rebuilt with a new hostname and label, it will still have same dmi.system.uuid and will be ignored by Satellite when reported by virt-who. Consequently, the guest mappings on the rebuilt hypervisor will also be ignored.

This duplicate detection is not affected by the virt-who config setting of hypervisor_id=, which only shows how the Content Host is displayed within the Satellite.

Diagnostic Steps

• The hypervisor and guest mapping can be observed by running # virt-who --one-shot --debug. The following example shows a hypervisor with two guests.

        {
            "hypervisorId": {
                "hypervisorId": "192.168.1.126"
            }, 
            "name": "192.168.1.126", 
            "guestIds": [
                {
                    "guestId": "5e67d2a1-2035-4ad5-be1a-4b3737121fbd", 
                    "state": 1, 
                    "attributes": {
                        "active": 1, 
                        "virtWhoType": "rhevm"
                    }
                }, 
                {
                    "guestId": "84cf58fe-da95-4643-936a-c133ec431b0a", 
                    "state": 1, 
                    "attributes": {
                        "active": 1, 
                        "virtWhoType": "rhevm"
                    }
                }, 
], 
            "facts": {
                "hypervisor.type": "qemu", 
                "dmi.system.uuid": "4C4C4544-0054-4E10-804C-B4C04F343832", 
                "cpu.cpu_socket(s)": "1", 
                "hypervisor.cluster": "MyCluster_cluster_41", 
                "hypervisor.version": "vdsm-4.19.31-1.el7ev"
            }

• The above hypervisor can then be compared to the one the Satellite already knows about by searching the existing hosts for a matching dmi.system.uuid value.

# hammer host list --search="facts.dmi::system::uuid=4C4C4544-0054-4E10-804C-B4C04F343832"

• If the resulting host reported by Satellite differs from the one being reported by virt-who, then the virt-who result is being ignored as a duplicate. Deleting the Content Host of the hypervisor from Satellite, and then re-executing a # virt-who --one-shot should then create the hypervisor from virt-who as a Content Host and pass along its guest mappings.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.