Description of problem: In some cases we have seen that the FQDN of the RHEL host has been used while running the 'hosted-engine --deploy' script, which can result in a fully functional VM, but a script that never thinks the VM is running. Version-Release number of selected component (if applicable): ovirt-engine-hosted-setup How reproducible: Steps to Reproduce: 1. Begin hosted-engine --deploy set up 2. Use host's resolvable FQDN when prompted for the VM's FQDN 3. Observe installation continue normally until it tries to verify a connection to the VM Actual results: During the first phase of installation the hosted-engine script has checked to ensure that the FQDN of the RHEV-M is resolvable using the 'dig' command. Disregarding it's uniqueness, if the FQDN resolves the script proceeds as normal. hosted-engine script can not make a connection to the HealthStatus page served by the RHEV-M VM, thus installation never finishes. Expected results: Earlier in the process, while the user is submitting the properties for the RHEV-M VM, the FQDN may come back as resolved. If so, it should make sure it is not the same as the host's FQDN and prompt the user for a new FQDN. Additional info: This was discovered while investigating a case, however I have not had a chance to actually look at the source yet. I plan on doing so before setting flags on the bug in case I misread the entire situation.
(In reply to wdaniel from comment #0) > Description of problem: > > In some cases we have seen that the FQDN of the RHEL host has been used > while running the 'hosted-engine --deploy' script, which can result in a > fully functional VM, but a script that never thinks the VM is running. > > Version-Release number of selected component (if applicable): > ovirt-engine-hosted-setup > > How reproducible: > > > Steps to Reproduce: > 1. Begin hosted-engine --deploy set up > 2. Use host's resolvable FQDN when prompted for the VM's FQDN > 3. Observe installation continue normally until it tries to verify a > connection to the VM > > Actual results: > During the first phase of installation the hosted-engine script has checked > to ensure that the FQDN of the RHEV-M is resolvable using the 'dig' command. > Disregarding it's uniqueness, if the FQDN resolves the script proceeds as > normal. > > hosted-engine script can not make a connection to the HealthStatus page > served by the RHEV-M VM, thus installation never finishes. > > Expected results: > Earlier in the process, while the user is submitting the properties for the > RHEV-M VM, the FQDN may come back as resolved. If so, it should make sure it > is not the same as the host's FQDN and prompt the user for a new FQDN. > > Additional info: > This was discovered while investigating a case, however I have not had a > chance to actually look at the source yet. I plan on doing so before setting > flags on the bug in case I misread the entire situation. I understand your motivation, but users can do all sorts of bad choices and we can't think beforehand and adapt the code to prevent any possible mistake. What if they input an FQDN that points to some other engine? hosted-engine will think all is well - it has a VM, it has an engine, but the engine is not in the VM... Perhaps better text might be enough for this case? Current text is: "Please provide the FQDN for the engine you would like to use. This needs to match the FQDN that you will use for the engine installation within the VM:" Perhaps add a note saying something like: "Note: This FQDN is for the VM that will be created now, it should not point to the host (or to any other existing machine)."
(In reply to Yedidyah Bar David from comment #1) > (In reply to wdaniel from comment #0) > > Description of problem: > > > > In some cases we have seen that the FQDN of the RHEL host has been used > > while running the 'hosted-engine --deploy' script, which can result in a > > fully functional VM, but a script that never thinks the VM is running. > > > > Version-Release number of selected component (if applicable): > > ovirt-engine-hosted-setup > > > > How reproducible: > > > > > > Steps to Reproduce: > > 1. Begin hosted-engine --deploy set up > > 2. Use host's resolvable FQDN when prompted for the VM's FQDN > > 3. Observe installation continue normally until it tries to verify a > > connection to the VM > > > > Actual results: > > During the first phase of installation the hosted-engine script has checked > > to ensure that the FQDN of the RHEV-M is resolvable using the 'dig' command. > > Disregarding it's uniqueness, if the FQDN resolves the script proceeds as > > normal. > > > > hosted-engine script can not make a connection to the HealthStatus page > > served by the RHEV-M VM, thus installation never finishes. > > > > Expected results: > > Earlier in the process, while the user is submitting the properties for the > > RHEV-M VM, the FQDN may come back as resolved. If so, it should make sure it > > is not the same as the host's FQDN and prompt the user for a new FQDN. > > > > Additional info: > > This was discovered while investigating a case, however I have not had a > > chance to actually look at the source yet. I plan on doing so before setting > > flags on the bug in case I misread the entire situation. > > I understand your motivation, but users can do all sorts of bad choices and > we can't think beforehand and adapt the code to prevent any possible mistake. > What if they input an FQDN that points to some other engine? hosted-engine > will think all is well - it has a VM, it has an engine, but the engine is not > in the VM... > > Perhaps better text might be enough for this case? > > Current text is: "Please provide the FQDN for the engine you would like to > use. > This needs to match the FQDN that you will use for the engine installation > within the VM:" > > Perhaps add a note saying something like: > "Note: This FQDN is for the VM that will be created now, it should not point > to the host (or to any other existing machine)." That sound like a great idea! I'm sorry to say that I still have not looked through the source code, but I believe some clarification text on that step would be very helpful. Could we also provide this clarification in the Self-Hosted Installation docs?
(In reply to wdaniel from comment #2) > That sound like a great idea! I'm sorry to say that I still have not looked > through the source code, but I believe some clarification text on that step > would be very helpful. Could we also provide this clarification in the > Self-Hosted Installation docs? For the docs you'll have to open a bz against the documentation, will be taken by the doc team.
ok, ovirt-hosted-engine-setup-1.1.2-5.el6ev.noarch ... Please provide the FQDN for the engine you would like to use. This needs to match the FQDN that you will use for the engine installation within the VM. Note: This will be the FQDN of the VM you are now going to create, it should not point to the base host or to any other existing machine. Engine FQDN: ...
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. http://rhn.redhat.com/errata/RHBA-2014-0505.html