ovirt-hosted-engine-cleanup will only operate on the host you run it on. In a cluster that might have side-effects, but as a rule it will try to undo all configuration settings that had a Linux host become an HCI member or just a host under oVirt management.
While the GUI will try to do the same with Ansible only, the script seems to do a little more and be more thorough. My guess is that it's somewhat of a leftover from the older 'all scripts' legacy of oVirt, before they re-engineered much of it to fit Ansible. It's not perfect, however. I have come across things that it would not undo, and that were extremely difficult to find (a really clean re-install would then help). There was an issue around keys and certificates for KVM that I only remember as a nightmare and more recently I had an issue with it's ansible scripts inserting an LVM device filter specific for a UID that the HCI setup wizard had created, which then precluded it ever working again after running the *cleanup scripts. All I got was "device excluded by a filter" and only much later I found the added line in /etc/lvm.conf not undone, which caused this nail-biter. But generally that message "Is hosted engine setup finished?" mostly indicates that the four major daemons for HCI still have issues. It all starts with glusterd: If you just added a host in HCI with storage, that would like to be properly healed. AFAIK that doesn't actually preclude already using the machine to host VMs, but in the interest of keeping your head clear, I'd suggest concentrating on getting the storage all clean, with gluster happily showing connectivity all around (gluster volume status all etc.) and 'gluster volume heal <volume> [info]' giving good results. Then you need to check on the services ovirt-ha-broker and ovirt-ha-agent as well as vdsmd via 'servicectl status <servicename>' to see what they are complaining about. I typically restart them in this order to iron out the bumps. As long as you give them a bit of time, restarting them periodically doesn't seem to do any harm, but helps them recover from hangs. And then you simply need patience: Things don't happen immediately in oVirt, because few commands ever intervene into anything directly. Instead they set flags here and there which then a myriad of interlocking state machine gears will pick up and respond to, to do things in the proper order and by avoiding the race conditions manual intervention can so easily cause. Even the fastest systems won't give results in seconds. So have a coffee, better yet, some herbal tea, and then look again. There is a good chance oVirt will eventually sort it out (but restarting those daemons really can help things along, as will looking at those error messages and their potential cause). _______________________________________________ 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/C7OV4GPTDVRTTEVE6QFO7TDA4LZIL7XC/
