Description of problem: ovirt-hosted-engine-setup asks for engine FQDN during --restore-from-file too : prompttext=_( 'Please provide the FQDN for the engine ' 'you would like to use.\nThis needs to match ' 'the FQDN that you will use for the engine ' 'installation within the VM.\n' 'Note: This will be the FQDN of the VM ' 'you are now going to create,\nit should not ' 'point to the base host or to any other ' 'existing machine.\nEngine FQDN: ' ), If the user does not enter the same FQDN as it is in the backup file, the deployment fails: 2020-09-17 15:22:24,268-0300 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:107 AuthError: Error during SSO authentication access_denied : Cannot authenticate user 'None@N/A': No valid profile found in credentials.. Because of this: 2020-09-17 15:22:23,969-03 ERROR [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-1) [] Cannot authenticate using authentication Headers: server_error: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@78611b42; line: 1, column: 2] 2020-09-17 15:22:23,986-03 ERROR [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-1) [] OAuthException access_denied: Cannot authenticate user 'None@N/A': No valid profile found in credentials. This is due to the FQDN mismatch on the restored configuration with what is configured on the new SHE VM. Could you please investigate if it is possible to use the FQDN from the backup file and not even ask this, or validate the FQDN against the value on the backup file. If not possible, maybe improve the dialog text to explain that SHE restore from backup is not the time to change FQDN. Although the documentation states the same FQDN needs to be used, a proper check on during deployment can help customers to avoid customers hitting problems during restore and move to SHE.
What should be exact steps for reproduction? What the patch is fixing?
(In reply to Nikolai Sednev from comment #1) > What should be exact steps for reproduction? > What the patch is fixing? 1. Backup the engine 2. On a new host run hosted-engine --deploy --restore-from-file=backup_file Before this patch, you have to enter the same FQDN as you used in the backup. This patch fetches the FQDN from the backup file and you don't need to enter it during the deployment. Look at the steps from https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/migrating_from_a_standalone_manager_to_a_self-hosted_engine/restoring_the_backup_on_a_new_self-hosted_engine_migrating_to_she With the patch, we don't need step 8.
Asaf, how's this for a release note? Before this update, when restoring a self-hosted engine you needed to enter the same FQDN that you used in the backup. With this update, when you run `hosted-engine --deploy --restore-from-file=backup_file` deploy script fetches the FQDN from the backup file and you don't need to enter it.
The FQDN is inherited properly from backup file, but then comes question: [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from backup file. Please provide the domain name you would like to use for the engine appliance. Engine VM domain: [qa.lab.tlv.redhat.com] Why do I need to confirm an obvious "Engine VM domain" if it exists in backup file? Tested on: ovirt-ansible-collection-1.2.2-1.el8ev.noarch ansible-2.9.14-1.el8ae.noarch ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch rhvm-appliance-4.4-20201111.0.el8ev.x86_64 Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.3 (Ootpa) Please refine also "Engine VM domain".
(In reply to Nikolai Sednev from comment #8) > The FQDN is inherited properly from backup file, but then comes question: > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > backup file. > Please provide the domain name you would like to use for the > engine appliance. > Engine VM domain: [qa.lab.tlv.redhat.com] > Why do I need to confirm an obvious "Engine VM domain" if it exists in > backup file? Can you please point me to where the "Engine VM domain" shows in the backup file? > > Tested on: > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > ansible-2.9.14-1.el8ae.noarch > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux release 8.3 (Ootpa) > > Please refine also "Engine VM domain".
(In reply to Asaf Rachmani from comment #9) > (In reply to Nikolai Sednev from comment #8) > > The FQDN is inherited properly from backup file, but then comes question: > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > backup file. > > Please provide the domain name you would like to use for the > > engine appliance. > > Engine VM domain: [qa.lab.tlv.redhat.com] > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > backup file? > > Can you please point me to where the "Engine VM domain" shows in the backup > file? > > > > > Tested on: > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > ansible-2.9.14-1.el8ae.noarch > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > x86_64 x86_64 GNU/Linux > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > Please refine also "Engine VM domain". I'm not aware of the direct place, the question comes right after FQDN being provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM domain" does not exists in the backup, we can get it from FQDN.
Created attachment 1730495 [details] backup file from engine
(In reply to Nikolai Sednev from comment #10) > (In reply to Asaf Rachmani from comment #9) > > (In reply to Nikolai Sednev from comment #8) > > > The FQDN is inherited properly from backup file, but then comes question: > > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > > backup file. > > > Please provide the domain name you would like to use for the > > > engine appliance. > > > Engine VM domain: [qa.lab.tlv.redhat.com] > > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > > backup file? > > > > Can you please point me to where the "Engine VM domain" shows in the backup > > file? > > > > > > > > Tested on: > > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > > ansible-2.9.14-1.el8ae.noarch > > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > > x86_64 x86_64 GNU/Linux > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > Please refine also "Engine VM domain". > > I'm not aware of the direct place, the question comes right after FQDN being > provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is > nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM > domain" does not exists in the backup, we can get it from FQDN. AFAIK the hostname in FQDN might contain a dot (.), so we cannot be sure what is the correct domain name. If you think the host cannot contain a dot, please open another RFE to remove the question about the domain name. Please note that we have the same question during the normal HE deployment (not restore from file).
(In reply to Asaf Rachmani from comment #12) > (In reply to Nikolai Sednev from comment #10) > > (In reply to Asaf Rachmani from comment #9) > > > (In reply to Nikolai Sednev from comment #8) > > > > The FQDN is inherited properly from backup file, but then comes question: > > > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > > > backup file. > > > > Please provide the domain name you would like to use for the > > > > engine appliance. > > > > Engine VM domain: [qa.lab.tlv.redhat.com] > > > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > > > backup file? > > > > > > Can you please point me to where the "Engine VM domain" shows in the backup > > > file? > > > > > > > > > > > Tested on: > > > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > > > ansible-2.9.14-1.el8ae.noarch > > > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > > > x86_64 x86_64 GNU/Linux > > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > > > Please refine also "Engine VM domain". > > > > I'm not aware of the direct place, the question comes right after FQDN being > > provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is > > nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM > > domain" does not exists in the backup, we can get it from FQDN. > > AFAIK the hostname in FQDN might contain a dot (.), so we cannot be sure > what is the correct domain name. > If you think the host cannot contain a dot, please open another RFE to > remove the question about the domain name. > Please note that we have the same question during the normal HE deployment > (not restore from file). So if we have the same question during initial deployment, the this value have to be saved to backup file. Can you check if it is there? Please see the attached backup file.
(In reply to Nikolai Sednev from comment #13) > So if we have the same question during initial deployment, the this value > have to be saved to backup file. Can you check if it is there? Please see > the attached backup file. We have it in the backup file. Please open another RFE/bug for that.
Opened as required https://bugzilla.redhat.com/show_bug.cgi?id=1900551
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 (RHV RHEL Host (ovirt-host) 4.4.z [ovirt-4.4.4]), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:0382
Due to QE capacity, we are not going to cover this issue in our automation