You could also go database diving. I had an issue where I tried to import a VM from my export domain and it just got hung. I tried running the unlock_entity script but it just kept failing. It sat there for months stuck, and found http://lists.ovirt.org/pipermail/users/2015-April/032346.html Of course deleting something from your database is quite permanent. I would wait and upgrade to 4.1.7, but something like the below should work. But probably not recommended Drop into postgres psql -d engine -U postgres List your tasks and grab the job_id select * from job order by start_time desc; select DeleteJob('8424f7a9-2a4c-4567-b528-45bbc1c2534f'); Where the string here is the job ID On Fri, Nov 10, 2017 at 9:48 AM, <nicolas@devels.es> wrote:
El 2017-11-10 14:41, Gianluca Cecchi escribió:
On Fri, Nov 10, 2017 at 3:34 PM, <nicolas@devels.es> wrote:
oVirt upgrade to 4.1.7 will probably cleanup this stale task.
However, if you want to do it before upgrading, run this command:
PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t all -u engine
Note that unlock_entity.sh has many flags and this is just an example (should clean all stale tasks).
You can find the PGPASSWORD value in the /etc/ovirt-engine/engine.conf.d/10-setup-database.conf file. As of 4.2 you won't need to supply credentials anymore [1].
Regards,
Nicolás
It seems it didn't work as expected. I got this at command line output
"
select fn_db_unlock_all();
INSERT 0 1 unlock all completed successfully. "
This is expected.
But the task remains in webadmin gui and I got an alert message in
alert section, of this type " /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh : System user root run manually unlock_entity script on entity [type,id] [all,] with db user engine "
I've seen this behavior too. IIRC the stale cleaning was not instant, it took some time to be applied.
Regards.
Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users