Bug 1687378 - Create host for esxi hypervisor fails with Validation failed: Name has already been taken error
Summary: Create host for esxi hypervisor fails with Validation failed: Name has alread...
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hosts - Content
Version: 6.3.5
Hardware: Unspecified
OS: Linux
high vote
Target Milestone: Released
Assignee: Justin Sherrill
QA Contact: Stephen Wadeley
Depends On:
Blocks: 1715827
TreeView+ depends on / blocked
Reported: 2019-03-11 12:19 UTC by hprakash
Modified: 2019-10-07 17:20 UTC (History)
11 users (show)

Fixed In Version: tfm-rubygem-katello-
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1715827 (view as bug list)
Last Closed: 2019-05-14 12:40:29 UTC

Attachments (Terms of Use)
6.3 patch (6.21 KB, patch)
2019-03-14 14:30 UTC, Justin Sherrill
no flags Details | Diff
6.3 hotfix tar (7.29 MB, application/x-tar)
2019-03-15 14:01 UTC, Justin Sherrill
no flags Details
HF-1687378-6.4.3-2.tar (8.24 MB, application/x-tar)
2019-05-21 16:21 UTC, Mike McCune
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:40:36 UTC
Foreman Issue Tracker 26351 None None None 2019-03-13 21:07:14 UTC
Foreman Issue Tracker 26376 None None None 2019-03-19 06:09:06 UTC

Description hprakash 2019-03-11 12:19:53 UTC
Description of problem:
After virt-who reports esxi hypervisors(and its guests), host for the hypervisor is not created on the Satellite

The task which gathers hypervisor details and registers the host for hypervisor is 'Actions::Katello::Host::HypervisorsUpdate'. It is failing with the error-

Validation failed: Name has already been taken

Object is validated by method create_host_for_hypervisor which is defined in-

rhsm.log shows the mappings similar to the below-
            "hypervisorId": {
                "hypervisorId": "ae9a8e11-79f3-11e1-a6a1-5cf3fc6e5a48"
            "name": "localhost", 
            "guestIds": [
                    "guestId": "531a05bd-1ee9-f293-f359-5e6b1eaa3206", 
                    "state": 5, 
                    "attributes": {
                        "active": 0, 
                        "virtWhoType": "esx"
                },##guests object truncated 
            "facts": {
                "hypervisor.type": "VMware ESXi", 
                "cpu.cpu_socket(s)": "2", 
                "hypervisor.cluster": "Public-36", 
                "hypervisor.version": "6.0.0"
            "hypervisorId": {
                "hypervisorId": "14a0a7b3-aa90-11e1-9780-3440b5be06a2"
            "name": "localhost", 
            "guestIds": [
                    "guestId": "341b0849-74cf-05c1-c0e2-520c0c6a03cc", 
                    "state": 1, 
                    "attributes": {
                        "active": 1, 
                        "virtWhoType": "esx"
                }##guests object truncated 
            "facts": {
                "hypervisor.type": "VMware ESXi", 
                "cpu.cpu_socket(s)": "2", 
                "hypervisor.cluster": "Shared",
                 "hypervisor.version": "6.0.0"

Note: above mappings have the SAME NAME for all the hypervisors. Due to the same hypervisor name, host is not getting created. To overcome this same name situation, we tried to modify the virt-who configuration to use the uuid e.g.-
hypervisor_id=uuid ###========> UUID

But above does not helps. 

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

How reproducible:

Steps to Reproduce:

Actual results:
Currently in Sat 6.3 changing the hypervisor_id=uuid in virt-who config is not forcing Satellite to register the systems to use the virt-who-<uuid> names

Expected results:
If the reported hypervisor have the same names then changing the virt-who config to use the UUID(hypervisor_id=uuid) should force Satellite to register the hypervisor host with the uuid e.g. virt-who-<uuid> instead of virt-who-<hostname>

Additional info:
virt-who reporting is fine
virt-who configuration is also fine

Comment 3 Evgeni Golov 2019-03-11 12:25:03 UTC
This is either Katello (Hosts - Content) or Candlepin, not virt-who config plugin, moving.

Comment 5 Justin Sherrill 2019-03-13 21:07:13 UTC
Connecting redmine issue https://projects.theforeman.org/issues/26351 from this bug

Comment 7 Justin Sherrill 2019-03-14 14:28:31 UTC
Attaching patch for 6.3, to apply the patch:

1.  Download the patch file
2.  cd /opt/theforeman/tfm/root/usr/share/gems/gems/katello-
3.  patch -p1 < ~/uuid.patch
4.  systemctl restart foreman-tasks httpd

Comment 8 Justin Sherrill 2019-03-14 14:30:11 UTC
Created attachment 1544092 [details]
6.3 patch

Comment 12 Justin Sherrill 2019-03-15 14:00:43 UTC
Attaching Hotfix:

Installation instructions:

1) download attached hotfix RPMs tar file to your Satellite
2) Extract the tar file
3) yum update *.rpm
4) systemctl restart httpd foreman-tasks
5) 'hammer ping' to ensure things looks good
6) resume operations

Comment 13 Justin Sherrill 2019-03-15 14:01:56 UTC
Created attachment 1544478 [details]
6.3 hotfix tar

Comment 15 Bryan Kearney 2019-03-18 20:03:20 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/26351 has been resolved.

Comment 28 errata-xmlrpc 2019-05-14 12:40:29 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.


Comment 31 Mike McCune 2019-05-21 16:21:04 UTC
There was an error in the previous hotfix in comment #29, DO NOT USE HF-1687378-6.4.3.tar

** Satellite 6.4.3 Hotfix 2 **

1) download HF-1687378-6.4.3-2.tar from bugzilla to Satellite 6.4.2 server

2) unpack and install:

rpm -Uvh tfm-rubygem-katello- tfm-rubygem-katello-doc-

3) restart services

foreman-maintain service restart

4) resume operations

Comment 32 Mike McCune 2019-05-21 16:21:38 UTC
Created attachment 1571704 [details]

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