How to register multiple Content Hosts with same UUID to Red Hat Satellite 6?

Solution Verified - Updated -

Environment

  • Red Hat Satellite 6.5 and above.
  • Red Hat Enterprise Linux with subscription-manager

Issue

  • How can I register multiple machines which have the same UUID (BIOS/Motherboard ID) to Red Hat Satellite 6.5?
  • The system properly registered and subscribe to Red Hat Satellite is not visible on the WebUI even after changing the context switch to any organization and any location.
  • Experiencing following error while trying to register Content Hosts with the same UUID to Red Hat Satellite 6.5:
HTTP error (500 - Internal Server Error): Multiple profiles found. Consider removing XXX which match this host.

Resolution

  • A system's UUID is a motherboard product UUID, which is set by the hardware vendor and is encoded into the BIOS and should always be unique.

  • However, if the hardware manufacturer for some reason has set the same UUID for multiple machines you will have to create a custom fact for every machine in order to register them as separate entities with Red Hat Satellite 6.5 or the Red Hat Customer Portal:

[root@client ~]# vi /etc/rhsm/facts/uuid.facts 
{"dmi.system.uuid": "customuuid"}

* customuuid = hostname which is unique for every machine.
  • With Red Hat Satellite 6.6 the following works:
[root@client ~]# subscription-manager facts|grep dmi.system.uuid
dmi.system.uuid: 45AA7104-5CB0-4A75-945D-7173C8DC5783

Administer > Settings > Content(tab) > Host Duplicate DMI UUIDs - Add the UUID in the form of an array

- Reregister client machine. (Reregistering of both systems may be needed if the profile was unregistered by using the --force option)

- Verify that UUID in systems is different from the client machine:
Hosts -> All Hosts -> Client machine -> facts -> dmi -> systems
  • If registering to the Red Hat Customer Portal, navigate to the Systems page and search for your new and old host after reregistering.

Root Cause

  • The subscription-manager when trying to register a Content Host to Red Hat Satellite or Red Hat Customer Portal looks for dmi.system.uuid parameter that should be unique.
  • Creating a custom fact at /etc/rhsm/facts/ on the Content Host takes precedence over subscription-manager facts located in /var/lib/rhsm/facts/.

Diagnostic Steps

Check for duplicate resource errors like the one below in /var/log/foreman/production.log

2020-05-10T20:00:49 [E|kat|388f6507] POST: https://satellite.example.com/pulp/api/v2/consumers/: {"id":"ede5aaea-f460-48fb-aa2a-f8d49c7eb373","display_name":"client.example.com"}: {"content_type"=>"application/json", "accept"=>"application/json"}
409 Conflict: {"error": {"code": "PLP0018", "data": {"resource_id": "ede5aaea-f460-48fb-aa2a-f8d49c7eb373"}, "description": "Duplicate resource: ede5aaea-f460-48fb-aa2a-f8d49c7eb373", "sub_errors": []}, "http_request_method": "POST", "exception": null, "error_message": "Duplicate resource: ede5aaea-f460-48fb-aa2a-f8d49c7eb373", "_href": "/pulp/api/v2/consumers/", "http_status": 409, "resource_id": "ede5aaea-f460-48fb-aa2a-f8d49c7eb373", "traceback": null}

Check for duplicate RHSM facts between 2 hosts in /var/lib/rhsm/facts/facts.json:

{"dmi.system.uuid": "Not Present", "proc_cpuinfo.common.cpuid_level": "13", "virt.host_type": "kvm", "dmi.bios.address": "0xe8000", "lscpu.l1d_cache": "32K", "dmi.chassis.manufacturer": "QEMU", "distribution.name": "Red Hat Enterprise Linux Server", "lscpu.l1i_cache": "32K", "dmi.chassis.security_status": "Unknown", "dmi.memory.error_correction_type": "Multi-bit ECC", "dmi.processor.type": "Central Processor", 
--snip--
"dmi.memory.array_handle": "0x1000", "dmi.system.sku_number": "Not Specified", "dmi.processor.asset_tag": "Not Specified", "dmi.meta.cpu_socket_count": "8", "dmi.system.wake-up_type": "Power Switch"}

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.

6 Comments

This article does not give explicit directions on how to register two separate computers which have identical DMI UUIDs - it only gives hints. What in the world is: Administer > Settings > Content(tab) > Host Duplicate DMI UUIDs - Add the UUID in the form of an array supposed to mean?

I think the answer is you can't have 2 with the same uuid. So you just change it on one, the new one, so then you can register it.

# uuidgen
ac84d6c5-b4aa-4d9f-99b1-f8ca376c3365
# vi /etc/rhsm/facts/uuid.facts 
{"dmi.system.uuid": "customuuid"}
put the number from uuidgen above in place of customuuid
So it would look like
{"dmi.system.uuid": "ac84d6c5-b4aa-4d9f-99b1-f8ca376c3365"}

I am not sure if case matters, might have to run over it with ~ to change it to upper case.

This is correct. DMI UUIDs are supposed to be unique, as they are the authoritative identification for a system. (Not even MAC addresses are guaranteed to be unique).

I am curious as to what 'hardware' is presenting non-unique UUIDs? The only time we've seen this, it has been a bug and needed investigation from the HW maker.

More times than not, this is seen in UNIQUE instances of cloning while subscribed. RHSM cached facts are held in /var/lib/rhsm/ with the old UUID. The issue and default go-to for a lot of procedures when using cloning is to register --force during their clone automation builds. I know it would be a performance impact of a little time, but perhaps we should include the regeneration of facts with a registration using --force?

On newly cloned machines, is it safe to delete the cached content of /var/lib/rhsm/ or is there a way to force the regeneration of these facts before trying to join the cloned system?

VMware cloning is an example of "hardware" that can produce duplicate UUID. I solved editing .vmx file with: uuid.bios = ""