[ovirt-users] hosted-Engine setup: hostname 'node01.example.com' doesn't uniquely match the interface selected for the management bridge

[mots]

Hello,

I'm trying to install Ovirt 4 on a new set of hosts. During "hosted-engine --deploy" I get the following error: (personal information is replaced with generic placeholders)

[ INFO  ] Stage: Setup validation
[ ERROR ] Failed to execute stage 'Setup validation': hostname 'node01.example.com' doesn't uniquely match the interface 'ens802f1' selected for the management bridge; it matches also interface with IP set(['192.168.99.10']). Please make sure that the hostname got from the interface for the management network resolves only there.
[ INFO  ] Stage: Clean up
[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20160705144908.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Hosted Engine deployment failed: this system is not reliable, please check the issue, fix and redeploy
          Log file is located at /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20160705144711-tl98lx.log

That IP "192.168.99.10" doesn't resolve to anything, because I haven't added it to the DNS server. It's also not in /etc/hosts.
It's just the IP for the storage network that doesn't use DNS at all.

>From the log:

2016-07-05 14:49:08 DEBUG otopi.plugins.gr_he_common.network.bridge bridge._get_hostname_from_bridge_if:274 Network info: {'netmask': u'255.255.255.0', 'ipaddr': u'192.168.10.194', 'gateway': u'192.168.10.2'}
2016-07-05 14:49:08 DEBUG otopi.plugins.gr_he_common.network.bridge bridge._get_hostname_from_bridge_if:310 hostname: 'node01.example.com', aliaslist: '[]', ipaddrlist: '['192.168.99.10', '192.168.10.194']'
2016-07-05 14:49:08 DEBUG otopi.context context._executeMethod:142 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod
    method['method']()
  File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-common/network/bridge.py", line 327, in _get_hostname_from_bridge_if
    o=other_ip,
RuntimeError: hostname 'node01.example.comh' doesn't uniquely match the interface 'ens802f1' selected for the management bridge; it matches also interface with IP set(['192.168.99.10']). Please make sure that the hostname got from the interface for the management network resolves only there.
2016-07-05 14:49:08 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Setup validation': hostname 'node01.example.com' doesn't uniquely match the interface 'ens802f1' selected for the management bridge; it matches also interface with IP set(['192.168.99.10']). Please make sure that the hostname got from the interface for the management network resolves only there.

The output for dig:

[root at node01 ~]# dig node01.example.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> node01.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45269
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;node01.example.com.     IN      A

;; ANSWER SECTION:
node01.example.com. 3600 IN      A       192.168.10.194

;; AUTHORITY SECTION:
example.com       900     IN      NS      dns.example.com.

;; ADDITIONAL SECTION:
dns.example.com. 900 IN      A       192.168.10.61

;; Query time: 3 msec
;; SERVER: 192.168.10.61#53(192.168.10.61)
;; WHEN: Die Jul 05 15:14:48 CEST 2016
;; MSG SIZE  rcvd: 110

Output for nslookup:

[root at node01 ~]# nslookup 192.168.99.10
Server:         192.168.10.61
Address:        192.168.10.61#53

** server can't find 10.99.168.192.in-addr.arpa.: NXDOMAIN

Why does the setup script think that my hostname resolves to 192.168.99.10?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 831 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160705/02a0e7b7/attachment.sig>