This saga is finally over, at least for now. I never succeeded in restoring
our hosted engine to a new iSCSI storage domain. For one reason or another,
however, I was able to restore it to a new NFS storage domain.
Any advice on the benefits or downsides of using an NFS storage domain versus
iSCSI for the self hosted engine would be greatly appreciated. At least for
now, however, things seem to be stable.
Just incase helps anyone else, here's a rough outline of the procedure I
finally used.
- set the cluster into global maintenance mode
- backup the engine using "engine-backup --scope=all --mode=backup
--file=backup.bck --log=backuplog.log"
- shutdown the engine
- restore the engine using "hosted-engine --deploy --4
--restore-from-file=backup.bck"
- when the restore pauses waiting for the lock file to be removed, scp
backup.bck to the new engine VM.
- ssh into the new VM, and restore the DBs using:
- engine-backup --mode=restore --file=backup.bck
--provision-all-databases --scope=db
- engine-backup --mode=restore --file=backup.bck
--provision-all-databases --scope=dwhdb
- engine-backup --mode=restore --file=backup.bck
--provision-all-databases --scope=grafanadb
- delete the lock file, and proceed as usual
Without manual intervention, the Postgres db on the new engine VM was never
initialized or setup.
Thanks again for everyones attention and advice.
Sincerely,
Devin
> On Nov 6, 2023, at 12:00 PM, Devin A. Bougie <devin.bou...@cornell.edu> wrote:
>
> Does anyone know how to regenerate
> /etc/ovirt-hosted-engine/hosted-engine.conf? Or where exactly I find each
> field to create the file manually?
>
> After trying to switch from an iscsi storage domain to NFS for the new hosted
> engine, I finally have the engine back up and running. However, when trying
> to reinstall a host to move it to the new hosted engine domain, I get "Failed
> to fetch hosted engine configuration file."
>
> /etc/ovirt-hosted-engine/hosted-engine.conf doesn't exist on the host I ran
> "hosted-engine --deploy" on. And on all other hosts, it still references the
> old hosted engine VM and storage domain.
>
> Thanks,
> Devin
>
>> On Oct 25, 2023, at 3:55 PM, Devin A. Bougie <devin.bou...@cornell.edu>
>> wrote:
>>
>> Thanks again, Gianluca.
>>
>> I'm currently ssh'd into the new local engine VM, and Postgres is running.
>> However, an engine DB doesn't exist? Should it at this point, and do you
>> have any other suggestions of where I should look?
>>
>> Devin
>>
>> ------
>> [root@lnxvirt-engine ~]# su - postgres
>> Last login: Wed Oct 25 15:47:18 EDT 2023 on pts/0
>> [postgres@lnxvirt-engine ~]$ psql
>> psql (12.12)
>> Type "help" for help.
>>
>> postgres=# \l
>> List of databases
>> Name | Owner | Encoding | Collate | Ctype | Access
>> privileges
>> -----------+----------+----------+-------------+-------------+-----------------------
>> postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 |
>> postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
>> | | | | |
>> postgres=CTc/postgres
>> template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
>> +
>> | | | | |
>> postgres=CTc/postgres
>> (3 rows)
>>
>> postgres=#
>> ------
>>
>>
>>> On Oct 25, 2023, at 12:40 PM, Gianluca Cecchi <gianluca.cec...@gmail.com>
>>> wrote:
>>>
>>>
>>> On Wed, Oct 25, 2023 at 5:50 PM Devin A. Bougie <devin.bou...@cornell.edu>
>>> wrote:
>>> I've had a chance to try this restore again, and this time login to the
>>> local (new) hosted-engine VM to verify that
>>> /root/DisableFenceAtStartupInSec.txt just contains:
>>> to
>>>
>>> And if I try the "engine-config -g DisableFenceAtStartupInSec" from the new
>>> hosted-engine VM, my connection closes.
>>> [root@lnxvirt-engine ~]# cat /root/DisableFenceAtStartupInSec.txt
>>> to
>>> [root@lnxvirt-engine ~]# set -euo pipefail && engine-config -g
>>> DisableFenceAtStartupInSec
>>> Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false
>>> Connection to the Database failed. Please check that the hostname and port
>>> number are correct and that the Database service is up and running.
>>> Connection to 192.168.222.25 closed.
>>>
>>> Any new suggestions or more tests I can run would be greatly appreciated.
>>>
>>> Thanks,
>>> Devin
>>>
>>>
>>> The key thing here is that for some reason it seems it is not able to
>>> connect to the database and so when "engine-config" command tries to get
>>> the second field of the output (the " | cut -d' ' -f2" part) it gets the
>>> "to" string here:
>>>
>>> Connection to the Database failed
>>> and anyway it returns error with failure of the overall playbook
>>> It should be investigated if there is a problem with the database itself on
>>> the new engine or if for some reason the "engine-config" command is not
>>> able to implicitly connect to the database
>>>
>>
>> _______________________________________________
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XJ6PEGB2LUCIOXJ5RKA35IUMIGR6LPIF/
>
> _______________________________________________
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/472WX3JWJNGD4NKTF4IOUTKXOTQTHORE/
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HHMC4K33N4VEQPZYWBWU4AKA5QVQAXRD/
