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 <giulio@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