[ovirt-users] Re: Barebone Hosted Engine Deployment fails

Good Evening - I wanted to let you know that I troubleshot this issue and have created a bug. Github: https://github.com/oVirt/ovirt-engine/issues/1016 If you are familiar with Ansible, you could also implement a work-around but it involves making a few changes to have a mechanism to pause/wait after the "TASK [ovirt.ovirt.engine_setup : Update all packages]" step during hosted-engine deploy. Here is what I did: - Modified Ansible task "engine_setup.yml" to include a "pause_execution.yml" task immediately after the "Update all packages" step. This is located in "/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/engine_setup/tasks/engine_setup.yml" on the host you are executing "hosted-engine --deploy" on. - included a copy of "pause_execution.yml" in the engine_setup role folder (ends up being ""/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/engine_setup/tasks/pause_execution.yml" - borrowing a copy from the "hosted_engine_setup" ansible role folder which is adjacent in the file system) The net result of these steps means the next time you execute the hosted-engine --deploy you can specify the ansible var that triggers the pause: For example: sudo hosted-engine --deploy --4 --ansible-extra-vars=he_pause_before_engine_setup=true You will be prompted for two pauses - the first time, identify and delete the lock file. The second time SSH, as the root user with the password specified during the hosted-engine deploy questionnaire, into the new ovirt-engine-appliance VM (the IP address is provided in the hosted-engine console output - for example 192.168.222.123) from another session on the host machine -- "ssh root(a)192.168.222.123" for example. Navigate to /etc/ovirt-engine/engine-config/engine-config.properties and vi the file. Find "ServerRebootSleepTime=Integer" (around Line 120) and edit this to read "ServerRebootSleepTime.type=Integer". Save and delete the lock file. The hosted-engine deployment should continue rather than fail. You can also verify, once you SSH into the new engine VM, that the problem exists and is fixed: To confirm the issue prior to changing engine-config.properties: "engine-config -l" should throw the "Index 1 out of bounds for length 1" error. After changing engine-config.properties: "engine-config -l" should tell you that it cannot find the database (which is expected because engine-setup hasn't run yet). If you are interested in pursuing this further (or if you run into trouble), please let me know and maybe we can figure out how to coordinate the details. I am hopeful that the source of the issue can be easily fixed and propagated into the official RPM to avoid it altogether. In any case, I really hope this helps! Best Regards, Dan