Bug 983295 - Unable to bypass FQDN requirement for rhevm-setup
Unable to bypass FQDN requirement for rhevm-setup
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: 3.3.0
Assigned To: Sandro Bonazzola
Ilanit Stein
: ZStream
Depends On:
Blocks: 1005851
  Show dependency treegraph
Reported: 2013-07-10 18:03 EDT by Bryan Yount
Modified: 2015-09-22 09 EDT (History)
11 users (show)

See Also:
Fixed In Version: is6
Doc Type: Bug Fix
Doc Text:
Previously, when installing Red Hat Enterprise Virtualization Manager, the system would not allow installation to proceed unless a fully qualified domain name (FQDN) was specified. This caused problems under some conditions, such attempting to install the Red Hat Enterprise Virtualization Manager in a lab where an FQDN may not be available. With this update, the Red Hat Enterprise Virtualization Manager can now be installed without specifying an FQDN unless in all-in-one configuration.
Story Points: ---
Clone Of:
Last Closed: 2014-01-21 12:34:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 446613 None None None Never
oVirt gerrit 16543 None None None Never

  None (edit)
Description Bryan Yount 2013-07-10 18:03:37 EDT
Description of problem:
When installing RHEV-M 3.2 in a lab or test environment where a FQDN might not always be available, the rhevm-setup script does not allow the user to bypass the FQDN requirement. While I agree that forcing FQDN for an enterprise product is the way to go, there should be a --flag to bypass this for certain instances if the user is made aware of the risks.

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

How reproducible:

Steps to Reproduce:
1. Configure a RHEL system without a FQDN such as an internal dynamic DNS environment in a lab
2. yum install rhevm
3. rhevm-setup

Actual results:
Install fails with error "Host fully qualified domain name. Note: this name should be fully resolvable  [quimby] : quimby.usersys.redhat.com"
The IP XX.XX.XX.XX does not hold a PTR record for the FQDN: quimby.usersys.redhat.com

Expected results:
The installer should have a --flag to allow the user to bypass the FQDN requirement and alert them of the risks and possibly require an additional Y/N answer.

Additional info:
This is necessary for setting up many of our internal Red Hat test environments.
Comment 2 Alon Bar-Lev 2013-07-11 03:22:59 EDT
This is in place because of these reasons:

1. libvirt requirement, as far as we know it tries to resolve the name and reverse resolve name when performing migration, so in aio configuration this is important.

2. ovirt-node/rhev-h require to access the engine via ssl, and host name must be resolvable.

3. users require to access the engine via ssl, and in order to avoid errors regarding host name mismatch there should be proper naming services.

But manual bypassing is important, and we have just had a discussion about this[1]

And in new installer we limited the reverse resolve to the aio configuration.

[1] http://gerrit.ovirt.org/#/c/16543/
Comment 3 Alon Bar-Lev 2013-08-14 05:10:33 EDT
This should be closed as CANTFIX or NOTBUG or anything...
Comment 4 Bryan Yount 2013-08-19 13:37:48 EDT
(In reply to Alon Bar-Lev from comment #2)
> But manual bypassing is important, and we have just had a discussion about
> this[1]
> And in new installer we limited the reverse resolve to the aio configuration.
> [1] http://gerrit.ovirt.org/#/c/16543/

Can we fix this in the next RHEV 3.2.z installer? Upping priority to high. This severely limits our ability to install RHEV in a lab environment that might not have DNS but where we could fake it with /etc/hosts entry.

Also, think about the customers... what if a customer wants to do a POC of RHEV but they don't have DNS for that environment? They will be dead in the water unless they install RHEV 3.1 first.
Comment 5 Chris Negus 2013-08-19 13:48:29 EDT
Forcing the RHEVM FQDN to forward/reverse resolve during rhevm-setup also breaks the procedure we are using for RHEV-M on HA cluster (https://access.redhat.com/site/node/216973). We don't set the IP address for the RHEV-M until we set up the cluster some time after rhevm-setup. That's because that IP address needs to move among different cluster nodes.
Comment 7 Alon Bar-Lev 2013-08-28 19:18:29 EDT
This should be resolved in 3.3.
Comment 8 Ilanit Stein 2013-09-01 02:50:12 EDT
This is not resolved yet on current formal release sf20.1 (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4.
Comment 9 Alon Bar-Lev 2013-09-01 04:32:03 EDT
(In reply to Ilanit Stein from comment #8)
> This is not resolved yet on current formal release sf20.1
> (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4.

This is not cloned bug for 3.2.z, it is the bug for 3.3.0.
Comment 10 Ilanit Stein 2013-09-08 04:05:48 EDT
Verified on is12: invalid fqdn in non interactive mode indeed allowed.
Comment 12 Charlie 2013-11-27 19:08:44 EST
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:


Thanks in advance.
Comment 14 errata-xmlrpc 2014-01-21 12:34:08 EST
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.


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