On Wed, 20 Oct 2021 at 12:36, David White <dmwhite...@protonmail.com> wrote:
> 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;* ? > It will be better to try to finalize the transfers first - POST path_to_your_engine/api/imagetransfers/<transfer-id>/finalize > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, October 20th, 2021 at 4:08 AM, Eyal Shenitzky < > eshen...@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 <dmwhite...@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 <https://protonmail.com/> Secure Email. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Tuesday, October 19th, 2021 at 6:57 AM, Eyal Shenitzky < >> eshen...@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 <dmwhite...@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 <https://protonmail.com/> Secure Email. >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Tuesday, October 19th, 2021 at 1:58 AM, Eyal Shenitzky < >>> eshen...@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 <dmwhite...@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 <https://protonmail.com/> Secure Email. >>>> >>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>> On Monday, October 18th, 2021 at 3:10 AM, Eyal Shenitzky < >>>> eshen...@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 <nsof...@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 -q* >>>>>> *Locked 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). >>>>>> [image: Screenshot from 2021-10-15 04-29-15.png] >>>>>> >>>>>> >>>>> Do you have active image transfers? >>>>> >>>>> You can check by getting >>>>> >>>>> https://myengine/ovirt-engine/api/imagetransfers >>>>> >>>>> If there are no image transfers, check the relevant disks status: >>>>> >>>>> https://myengine/ovirt-engine/api/disks/{id} >>>>> >>>>> 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-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/3UE6CJLEGBR27KWJQH3TA5AX7LXX5URV/ >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Eyal Shenitzky >>>> >>>> >>>> >>> >>> -- >>> Regards, >>> Eyal Shenitzky >>> >>> >>> >> >> -- >> Regards, >> Eyal Shenitzky >> >> >> > > -- > Regards, > Eyal Shenitzky > > > -- Regards, Eyal Shenitzky
_______________________________________________ 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/V6JLEB5QWGNQTLSU7FHWLHM6KZP7O7MB/
