Bug 1272820

Summary: Hostname is inconsistent between rhevh and rhevm after auto-install with management_server
Product: Red Hat Enterprise Virtualization Manager Reporter: Huijuan Zhao <huzhao>
Component: ovirt-nodeAssignee: Douglas Schilling Landgraf <dougsland>
Status: CLOSED WORKSFORME QA Contact: Huijuan Zhao <huzhao>
Severity: low Docs Contact:
Priority: medium    
Version: 3.5.5CC: cshao, cwu, ecohen, fdeutsch, gklein, huiwa, huzhao, leiwang, lsurette, lyi, yaniwang, ycui, ylavi
Target Milestone: ovirt-3.6.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: node
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-10 19:20:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot rhevh hostname
none
screenshot rhevm name
none
log hostname inconsistent none

Description Huijuan Zhao 2015-10-19 02:09:38 UTC
Created attachment 1084237 [details]
screenshot rhevh hostname

Description of problem:
After auto-install with management_server, rhevh register to rhevm successful, but the "Hostname" on rhevh is inconsistent with "name" on rhevm (FYI, screenshot in attach)

Version-Release number of selected component (if applicable):
rhev-hypervisor-6-6.7-20151015.1.el6ev
ovirt-node-3.2.3-23.el6.noarch

How reproducible:
test 2 times on machine dell-per510-01.qe.lab.eng.nay.redhat.com, both can reproduce.

Steps to Reproduce:
1. Auto install rhev-hypervisor-6-6.7-20151015.1.el6ev with parameters as follows:
storage_init=/dev/sda BOOTIF=em1 management_server=10.66.72.99:443 adminpw=OKr05SbCu3D3g firstboot
2. Check the Hostname on rhevh TUI, check the Name on rhevm.
 
Actual results:
After step2, the Hostname on rhevh TUI is "dell-per510-01.qe.lab.eng.nay.redhat.com",
the Name on rhevm is "localhost.localdomain".

Expected results:
Hostname on rhevh TUI should be same with the Name on rhevm.


Additional info:

Comment 1 Huijuan Zhao 2015-10-19 02:10:23 UTC
Created attachment 1084238 [details]
screenshot rhevm name

Comment 2 Huijuan Zhao 2015-10-19 02:12:09 UTC
Created attachment 1084239 [details]
log hostname inconsistent

Comment 3 Fabian Deutsch 2015-10-19 08:56:25 UTC
To me this looks like it could be a dupe of bug 1241712

Comment 4 Douglas Schilling Landgraf 2015-10-22 14:44:24 UTC
The vdsm-reg log shows that your system registered to RHEVM as hostname: localhost.localdomain.

=== vdsm.reg log ===
MainThread::DEBUG::2015-10-16 07:48:09,497::vdsm-reg-setup::140::root::registerVDS URI= /RHEVManagerWeb/VdsAutoRegistration.aspx?vds_ip=10.66.110.242&__VIEWSTATE=&vds_unique_id=4C4C4544-0058-3810-8033-B2C04F363358_00%3A1b%3A21%3A36%3A79%3Af0&vds_name=localhost.localdomain&ticket=&port=54321
=== vdsm.reg log ===

Could you please share the output of command below?
# cat /proc/sys/kernel/hostname

During my tests with the iso rhev-hypervisor-6-6.7-20151015.1.el6ev the hostname didn't change from localhost.localdomain. It seems we are affect to bz#1241712

Comment 5 Huijuan Zhao 2015-10-23 08:42:41 UTC
Douglas, I tested 4 times on the same machine: dell-per510-01.qe.lab.eng.nay.redhat.com, and 2 times on another machine, but can not reproduce this issue now. When I reported bug, I encountered this issue one more times.

I think this issue is probabilistic/race condition issue,I will lower the severity to low, and reserve for a period of time to see whether it can reproduce.

Comment 7 Douglas Schilling Landgraf 2015-11-10 19:20:50 UTC
(In reply to Huijuan Zhao from comment #5)
> Douglas, I tested 4 times on the same machine:
> dell-per510-01.qe.lab.eng.nay.redhat.com, and 2 times on another machine,
> but can not reproduce this issue now. When I reported bug, I encountered
> this issue one more times.
> 
> I think this issue is probabilistic/race condition issue,I will lower the
> severity to low, and reserve for a period of time to see whether it can
> reproduce.

Thanks Huijuan,

I am closing this bug for now, please re-open in case you see it again so we can research. The original bug in platform bz#1241712 was closed today by PM as well.