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).