Bug 1687378

Summary: Create host for esxi hypervisor fails with Validation failed: Name has already been taken error
Product: Red Hat Satellite 6 Reporter: hprakash
Component: Hosts - ContentAssignee: Justin Sherrill <jsherril>
Status: CLOSED ERRATA QA Contact: Stephen Wadeley <swadeley>
Severity: high Docs Contact:
Priority: high    
Version: 6.3.5CC: avettath, egolov, gscarbor, iwindon, jbhatia, jsenkyri, jsherril, kkohli, mmccune, nbansal, wpinheir
Target Milestone: 6.5.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: tfm-rubygem-katello- Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1715827 (view as bug list) Environment:
Last Closed: 2019-05-14 12:40:29 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:
Bug Depends On:    
Bug Blocks: 1715827    
Description Flags
6.3 patch
6.3 hotfix tar
HF-1687378-6.4.3-2.tar none

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]