Bug 1097762

build for 3.4.2 is due today, these won't make it and out of scope (not included in the rhev 3.4.2 tracker - [RHEV] 3.4.2 Bug tracker - https://bugzilla.redhat.com/show_bug.cgi?id=1123858.

moving to 3.4.3.

Forward and reverse lookup is a requirement for the RHEV-M (see [1]) as such we do not believe this is a valid bug.

For the record, if the RHEV-M does not have a valid forward/reverse lookup in the DNS server you will likely experience all sorts of issues with the hypervisors and need to resort to non-standard configuration.


[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html-single/Installation_Guide/index.html#Red_Hat_Enterprise_Virtualization_Manager_Configuration_Overview

Keith but it's not necessarily required for the host to be able to reverse-search the hostname:

"The host name is detected automatically, but you can correct this host name if it is incorrect or if you are using virtual hosts. There must be forward and reverse lookup records for the provided host name in DNS, especially if you will also install the reports server."

You can also alter it to something totally different from forward searchable DNS.

Thomas,
I am not following your logic.  It says right here...
- "There must be forward and reverse lookup records for the provided host name in DNS"

Which means that each hypervisor must have a forward and reverse lookup in the local DNS  server.

Yes Keith they must have these, however they do not need to be the same. Which was the deal in my case.

I can have DNS records

rhevm.example.com in forwards zone
while reverse is 
rhevm.example1.com

users will be going through the first one and if you override it during setup it will work fine for them, while machine is set with the second, which makes the automatic reverse search to fail.

But still this is a valid setup for RHEV and we don't restrict such usage.

(In reply to Tomas Dosek from comment #5)
> Yes Keith they must have these, however they do not need to be the same.
> Which was the deal in my case.
> 
> I can have DNS records
> 
> rhevm.example.com in forwards zone
> while reverse is 
> rhevm.example1.com
> 
> users will be going through the first one and if you override it during
> setup it will work fine for them, while machine is set with the second,
> which makes the automatic reverse search to fail.
> 
> But still this is a valid setup for RHEV and we don't restrict such usage.

I understand what you're saying but, I'm pretty sure that is neither the definition nor the spirit of "must be forward and reverse lookup records for the provided host name".  

In one direction, hostname[A] resolves to IP[A].  In the reverse direction, IP[A] resolves to hostname[B] which is != hostname[A].  If you want to use hostname[B], then hostname[A] needs to be an CNAME for hostname[B].

I got a customer hitting exact same error.
I asked him to check the reverse look up for RHEVM FQDN. Will update later.

3.4.3 build was delivered to QE, if this bugs isn't going to be fixed and shipped by 31/10, please move to 3.4.4.

I have a customer getting similar errors despite reverse look up working for RHEVM.

Let me know if logs required to check further.

pushing to 3.4.4, as seems like these bugs won't make it to the 3.4.3 release (last respin is due tomorrow).

As I mentioned in comment 2, it is required that the RHEV-M be reverse resolvable as outlined in the documentation.  Closing this BZ as this is a configuration problem.