
Hah. Wow. Thanks for your patience on this. lol. There they are! I just cross-checked these disk_id's, and can confirm these are the 3 that continue to show up in the oVirt UI. engine=# SELECT command_id, disk_id, last_updated, message, timeout_policy, type, active FROM image_transfers; command_id | disk_id | last_updated | message | timeout_policy | type | active --------------------------------------+--------------------------------------+----------------------------+-----------------------+----------------+------+-------- 2bf042e8-7ddd-4f43-a2b1-4a16de5c750a | 06bd3678-bfab-4793-a839-ec8cad4b96e5 | 2021-09-20 21:37:48.464-04 | Finalizing failure... | legacy | 2 | f b632c4ea-2e36-44d1-858f-de03895947b1 | e0f46dc5-7f98-47cf-a586-4645177bd6a2 | 2021-09-20 20:29:16.603-04 | Finalizing failure... | legacy | 2 | f b6a81f14-bf3d-467d-899c-4906fef35078 | 13cef086-3878-463b-a224-cc42b44d8468 | 2021-09-23 16:20:39.612-04 | Finalizing failure... | legacy | 2 | f (3 rows) Is it safe for me to simply run DELETE FROM image_transfers; ? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 20th, 2021 at 4:08 AM, Eyal Shenitzky <eshenitz@redhat.com> wrote:
Hi David,
Since you tried first to execute the query without semicolon the second attempt to run the query with the semicolon failed.It considers both lines as one query.
Try only - SELECT * FROM image_transfers;
On Tue, 19 Oct 2021 at 23:32, David White <dmwhite823@protonmail.com> wrote:
I tried that, but whenever I use semicolons, I get a syntax error. Here's my full stdout with and without the semicolon:
postgres=# \c engine You are now connected to database "engine" as user "postgres". engine=# SELECT * FROM image_transfers engine-# SELECT * FROM image_transfers; ERROR: syntax error at or near "SELECT" LINE 2: SELECT * FROM image_transfers; ^
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 19th, 2021 at 6:57 AM, Eyal Shenitzky <eshenitz@redhat.com> wrote:
You are missing ';' at the end of the query.
That's why you see no output.
On Tue, 19 Oct 2021 at 13:24, David White <dmwhite823@protonmail.com> wrote:
Thank you. However, that was one of the queries I already tried.
All of the queries I listed in my previous email returned empty results, which is why I was confused. Given the name of some of these tables, I expect to see some data in them. I just tried re-running that query, making sure to capitalize the "FROM" just in case, but got the same results:
engine=# SELECT * FROM image_transfers engine-#
I then went into the UI, and migrated a VM from 1 host to another. During the migration, I re-ran that query, and it still came back empty.
Does this table store information about moving a disk from 1 volume to another, or moving VMs from 1 host to another?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 19th, 2021 at 1:58 AM, Eyal Shenitzky <eshenitz@redhat.com> wrote:
Please try the following query and share the output -
SELECT * FROM image_transfers;
On Tue, 19 Oct 2021 at 03:48, David White <dmwhite823@protonmail.com> wrote:
Would this be found in the "image_transfers" table?
\dt shows me that there are 156 tables in the engine database. And I see an image_transfers table. But it looks empty, like a lot of other tables.
This seems strange to me. All of these tables are empty, unless I'm doing something wrong (I'm new to Postgres).
engine=# SELECT * from images engine-# SELECT * from image_transfers engine-# select * from users engine-# SELECT * from users engine-# SELECT * from cluster engine-# select * from vm_pools engine-# select * from vm_static
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, October 18th, 2021 at 3:10 AM, Eyal Shenitzky <eshenitz@redhat.com> wrote:
> The host cannot be set to maintenance if there are image transfer with status different then PAUSED (by user or system - 4/5 in the DB) or FINISHED (success or failure - 9/10 in the DB). >
> If there are image transfer session in the DB with status that is different then those that I mentioned, you should see why the have a different status and finalize/clean them before setting the host to maintenance. >
> On Sun, 17 Oct 2021 at 15:43, Nir Soffer <nsoffer@redhat.com> wrote: >
> > On Fri, Oct 15, 2021 at 11:38 AM David White via Users <users@ovirt.org> wrote: > >
> > > Thank you very much. > > > I was able to (re)set the `engine` user's password in Postgres. > > > Unfortunately, I'm still having trouble unlocking the disks. > > >
> > > The following command produces no output underneath "Locked disks" when I run this command on the hosted engine VM: > > >
> > > [root@ovirt-engine1 dwhite]# PGPASSWORD=snip /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -qLocked disks > > >
> > > However, in the oVirt UI, when I try to put the host into maintenance mode I continue to get the message that there are (3) locked disks (screenshot below). > > > [Screenshot from 2021-10-15 04-29-15.png] > >
> > Do you have active image transfers? > >
> > You can check by getting > >
> > If there are no image transfers, check the relevant disks status: > >
> > If the disks status is "locked", it may be engine bug, not cleaning up after > > failed image transfer. > >
> > If there is no task in engine using this disk, you can change the disk status using: > >
> > # sudo -u postgres psql -d engine > >
> > Finding the locked images: > >
> > # select image_group_id,imagestatus from images where imagestatus=2; > >
> > Unlocking an image: > >
> > # update images set imagestatus=1 where image_group_id='xxx-yyy'; > >
> > Nir_______________________________________________ > >
> > Users mailing list -- users@ovirt.org > >
> > To unsubscribe send an email to users-leave@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/3UE6CJLEGBR27K... >
> -- >
> Regards, > Eyal Shenitzky
--
Regards, Eyal Shenitzky
--
Regards, Eyal Shenitzky
--
Regards, Eyal Shenitzky