1:02 a.m.
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.bougie(a)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.bougie(a)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.cecchi(a)gmail.com>
wrote:
>>
>>
>> On Wed, Oct 25, 2023 at 5:50 PM Devin A. Bougie <devin.bougie(a)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(a)ovirt.org
> To unsubscribe send an email to users-leave(a)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/XJ6PEGB2LUC...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/472WX3JWJNG...