Since 6180c2e8-141a-4126-bcb1-5af5caa98175 doesn't exist on the VDSM, it
should be removed from the DB,
and since it's the parent id for image
e77e2773-eecb-46a6-87c7-14df14f7d95b, it also should be changed.
Something like this:
UPDATE images set parentid = '19fa612d-2f93-46a5-93e7-c74afc2937fa' where
image_guid = 'e77e2773-eecb-46a6-87c7-14df14f7d95b';
Then you can remove the 6180c2e8 image.
It will be safe if you'll have a backup before making any DB changes.
*Regards,*
*Shani Leviim*
On Thu, Apr 22, 2021 at 3:06 PM Giulio Casella <giu...@di.unimi.it> wrote:
>
>
> On 22/04/2021 13:20, Shani Leviim wrote:
> > Hi,
> > You can use the DeleteImage tool [1], but it's first recommended to
> > backup your engine.
> >
> > To be on the safe side, here are some checks it's better to execute
> > before deleting:
> > - In order to locate the illegal image, you can run this command on the
> > host:
> > vdsm-tool dump-volume-chains <sd_id>
>
> Ok, that is the relevant part of the output:
>
> image: 2fd9b340-14ce-42cd-a880-8f75eb3b72e7
>
> - 19fa612d-2f93-46a5-93e7-c74afc2937fa
> status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE, capacity: 53687091200, truesize: 45902462976
>
> - e77e2773-eecb-46a6-87c7-14df14f7d95b
> status: OK, voltype: LEAF, format: COW, legality: LEGAL,
> type: SPARSE, capacity: 53687091200, truesize: 27917287424
>
> So I have on storage two images, first one is a snapshot, second one is
> Active VM.
>
> Being the VM up and running I think I could say that on storage the
> situation is consistent.
>
> >
> > - It's also recommended to verify that the engine and vdsm are synced
> > about that image, once you've found it, by running this command on the
> > engine:
> > SELECT *
> > FROM images_storage_domain_view images_storage_domain_view
> > WHERE image_group_id = <image_group_id>;
> >
>
> That's the point: engine (database) sees 3 images, whilst vdsm sees only 2.
>
> And this is output of:
>
> select
>
> image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active
> from images where image_group_id='image-group-id';
>
> image_guid | parentid
> | imagestatus | vm_snapshot_id | volume_type
> | volume_format | active
>
> --------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
> 6180c2e8-141a-4126-bcb1-5af5caa98175 |
> 19fa612d-2f93-46a5-93e7-c74afc2937fa | 1 |
> 281a4331-89fa-4544-b6ab-22c0e5ac6459 | 2 | 4 | f
> 19fa612d-2f93-46a5-93e7-c74afc2937fa |
> 00000000-0000-0000-0000-000000000000 | 4 |
> 6488f4c8-efc4-43df-aafc-497fb7d51fbb | 2 | 4 | f
> e77e2773-eecb-46a6-87c7-14df14f7d95b |
> 6180c2e8-141a-4126-bcb1-5af5caa98175 | 1 |
> 59f69d6f-f300-45e4-8487-1fe4368a5933 | 2 | 4 | t
>
> So there is in the database an image (the one with image-guid
> "6180c2e8-141a-4126-bcb1-5af5caa98175") not existing on storage.
>
> > [1]
> > DeleteImage tool:
> > SELECT DeleteImage('image-id');
> >
> > DELETE
> > FROM images
> > WHERE image_guid = v_image_guid;
> >
>
> I think it could not be enough, I think I should adjust parentship
> relations in "images" table.
>
> Just looking at that table it seems not so difficult, but: is it
> sufficient? Is it safe?
>
> Regards,
> Giulio
>
>
_______________________________________________
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/D2HKS2RFMNKGP54JVA3D5MVUYKKQVZII/
