Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 830779

Summary: 3.1 - rhev-h: host install is initiated with localhost.localhost instead of name configured in console
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engineAssignee: Doron Fediuck <dfediuck>
Status: CLOSED NOTABUG QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: bazulay, dfediuck, dyasny, hateya, iheim, jboggs, lpeer, mburns, ovirt-maint, Rhev-m-bugs, sgrinber, yeylon, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 15:37:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log and screen shot none

Description Dafna Ron 2012-06-11 12:01:14 UTC
Description of problem:

I added the rhev-m in the rhev-h console and the install did not automatically intiate (as in the host was not added to my setup with waiting for approve). 
only when I added the host from the UI the host was added with waiting for approve 
tested for both 3.0 and 3.1 rhe-v setups. 

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

Red Hat Enterprise Virtualization Hypervisor release 6.3 (20120606.3)

How reproducible:

100%

Steps to Reproduce:
1. install rhev-h
2. try to initiate the install from the console 
3.
  
Actual results:

host is not added to the rhevm setup. 

Expected results:

host should be added to the rhevm setup

Additional info:

Comment 1 Perry Myers 2012-06-11 12:42:05 UTC
This functionality is controlled by vdsm (RHEV-M registration) so moving to the correct component.

Comment 2 Mike Burns 2012-06-11 13:27:06 UTC
first thing that vdsm team will ask for are the vdsm-reg logs from rhev-h.

Comment 3 Dafna Ron 2012-06-11 14:23:31 UTC
I did some more testing, I found that we do intiate the registration but it takes time because we are failing on https. 
having said that, I am not closing this bug only altering it since the registration is done with localhost.locathost although the network is configured.

MainThread::DEBUG::2012-06-11 14:25:08,351::vdsm-reg-setup::131::root::registerVDS URI= /RHEVManagerWeb/VdsAutoRegistration.aspx?vds_ip=10.35.XXX.15&vds_name=localhost.localdomain&vds_unique_id=44454C4C-3800-1046-8035-B1C04F34344A_00%3A22%3A19%3A14%3A7e%3Aca&port=54321&__VIEWSTATE=

and I am adding logs and screenshots (thanks mike :) forgot to add).

Comment 4 Dafna Ron 2012-06-11 14:30:26 UTC
Created attachment 590950 [details]
log and screen shot

Comment 5 Dafna Ron 2012-06-11 14:37:58 UTC
I am lowering priority since once we approve the host we can change the name manually.
but I am deducting that if I added more then one host we will fail on next host's with CanDoAction 'host name already exists'.

Comment 6 Itamar Heim 2012-06-11 20:35:05 UTC
there's supposed to be logic that sends the ip if hostname is localhost rather than configured (not sure if in engine or vdsm though)
so:
1. need to check why localhost was kept.
2. need to check why localhost was used to begin with, rather than the configured name

Comment 7 Doron Fediuck 2012-07-10 15:12:34 UTC
Dafna,
This is actually working by design.
In registration the backend will not change the machine's host name, only report
it, so it will be used by the backend.
The backend needs to be able to handle name duplication, for cases like this one
or dhacp names (dhcp-1-173 as a host name). So there's a mechanism to rename the
previous host name with the duplicate name, assuming that the new one is the correct one. 
You will not get a can-do-action error, since we're testing for machine ID, and not name.

Please try to register 2 localhost.localdomain rhev-h machines, and report the results.

Comment 16 Doron Fediuck 2012-08-07 15:37:30 UTC
After some internal checks, with Pavel's good assistance, we've established 
that this is working by design, as stated in comment 7.

Closing as this is not a bug.