Hello
We have the same issue, and not just one VM, we have about 10-15 VMs that have either
snapshots that are illegal or snapshots that is not possible to remove.
This have been an issue for quite some time, all since beginning of 4.3 we get "vm
with illegal snapshots" almost every week, and most often we can remove the snapshot
and all is ok, but now this have escalated quite much and leaves us with customer VM that
we may not be able to reboot or that the disk gets corrupted, that have happed a few
times.
[cid:2c902230-ccb6-4e63-98f6-ea667ba239bf]
This is the VM with most snapshots that we are unable to remove any of them.
Engine is on 4.3.10 and hosts on 4.3.9
How can i safely remove these snapshots?
(I am not super comfortable around database "hacking" so some informative
description would be much appreciated.)
And how can we eliminate that these things happen?
Cheers
Magnus
________________________________
From: Alex K <rightkicktech(a)gmail.com>
Sent: 10 November 2020 05:05
To: Giorgio Biacchi <giorgio(a)di.unimi.it>
Cc: users <users(a)ovirt.org>
Subject: [ovirt-users] Re: VM with illegal snapshots
On Fri, Oct 9, 2020, 12:59 Giorgio Biacchi
<giorgio@di.unimi.it<mailto:giorgio@di.unimi.it>> wrote:
Hi,
due to a bug in our Ovirt integrated backup system now we have some VMs
with snapshots in illegal state.
It seems that there's an inconsistency between the db and the real
status of images on disk.
Let me show an example:
engine=# select
image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active
from images where image_group_id='e34f77cb-54d5-40d0-b539-e0a5fd512d2d';
image_guid | parentid |
imagestatus | vm_snapshot_id | volume_type |
volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
a107b6c4-842e-4b40-9215-c965431a0c0f |
00000000-0000-0000-0000-000000000000 | 4 |
d19d6ca3-1989-4c67-8ee7-c0c43b3e6d74 | 2 | 4 | f
a4c86a68-9123-454c-b417-1b15038a4bf2 |
a107b6c4-842e-4b40-9215-c965431a0c0f | 1 |
e7a405ee-8fd4-4733-ae9c-5252bf07c9d3 | 2 | 4 | f
f6a61f2e-26bd-4b63-97c6-d66913ce48c5 |
a4c86a68-9123-454c-b417-1b15038a4bf2 | 1 |
9d0958b9-4995-4e11-a027-a32d4bac52e4 | 2 | 4 | t
(3 rows)
[root@host02 ~]# lvs -o+lv_tags |grep e34f77cb-54d5-40d0-b539-e0a5fd512d2d
a107b6c4-842e-4b40-9215-c965431a0c0f
459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi------- 149.50g
IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_68,PU_00000000-0000-0000-0000-000000000000
f6a61f2e-26bd-4b63-97c6-d66913ce48c5
459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi------- 10.00g
IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_348,PU_a107b6c4-842e-4b40-9215-c965431a0c0f
so image guid a4c86a68-9123-454c-b417-1b15038a4bf2 is not present on
disk, i think that the image was correctly merged but not removed from
the database.
Any suggestion on how to fix the database to reflect the real situation
on disk??
In those cases I delete the entry from engine DB to reflect the status of the image
chain.
TIA
--
gb
PGP Key:
http://pgp.mit.edu/
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
_______________________________________________
Users mailing list -- users@ovirt.org<mailto:users@ovirt.org>
To unsubscribe send an email to users-leave@ovirt.org<mailto: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/OF4NTAC6BPG...