Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hosts - Content
Version: 6.3.5
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: 6.5.0
Assignee: Justin Sherrill
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks: 1715827
TreeView+ depends on / blocked
 
Reported: 2019-03-11 12:19 UTC by hprakash
Modified: 2020-02-03 09:13 UTC (History)
11 users (show)

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


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


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 26351 0 Normal Closed allow for duplicate virt-who hypervisor names when uploading with hypervisor_id=uuid 2020-10-16 10:00:21 UTC
Foreman Issue Tracker 26376 0 Normal Closed remove lazy_accessor change tracking 2020-10-16 10:00:32 UTC
Red Hat Product Errata RHSA-2019:1222 0 None None None 2019-05-14 12:40:36 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-
/opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.4.5.87/app/lib/actions/katello/host/hypervisors_update.rb 

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.-
~~~
[virt-who-config-1]
type=esx
owner=OWNER
env=Library
server=<vmware-server>
username=<username>
encrypted_password=<Encrypted_password>
rhsm_hostname=<rhsm.hostname.com>
rhsm_username=virt_who_reporter_1
rhsm_encrypted_password=<Encrypted_Password>
rhsm_prefix=/rhsm
hypervisor_id=uuid ###========> UUID
~~~

But above does not helps. 

Version-Release number of selected component (if applicable):
satellite-6.3.5-1.el7sat.noarch
virt-who-0.22.5-1.el7.noarch

How reproducible:
Always

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.4.5.87/
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.

https://access.redhat.com/errata/RHSA-2019:1222

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-3.7.0.56-4.HOTFIXRHBZ1687378.el7sat.noarch.rpm tfm-rubygem-katello-doc-3.7.0.56-4.HOTFIXRHBZ1687378.el7sat.noarch.rpm

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]
HF-1687378-6.4.3-2.tar


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