3:32 p.m.
------=_Part_286_211283766.1440765137323
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
got exactly the same issue, with all nice side effects like performance
degradation. Until now i was not able to fix this, or to fool the engine somehow
that it whould show the image as ok again and give me a 2nd chance to drop the
snapshot.
in some cases this procedure helped (needs 2nd storage domain)
-> image live migration to a different storage domain (check which combinations
are supported, iscsi -> nfs domain seems unsupported. iscsi -> iscsi works)
-> snapshot went into ok state, and in ~50% i was able to drop the snapshot
than. space had been reclaimed, so seems like this worked
other workaround is through exporting the image onto a nfs export domain, here
you can tell the engine to not export snapshots. after re-importing everything
is fine
the snapshot feature (live at least) should be avoided at all currently....
simply not reliable enaugh.
your way works, too. already did that, even it was a pita to figure out where to
find what. this symlinking mess between /rhev /dev and /var/lib/libvirt is
really awesome. not.
Jan Siml <jsiml(a)plusline.net> hat am 28. August 2015 um 12:56
geschrieben:
Hello,
if no one has an idea how to correct the Disk/Snapshot paths in Engine
database, I see only one possible way to solve the issue:
Stop the VM and copy image/meta files target storage to source storage
(the one where Engine thinks the files are located). Start the VM.
Any concerns regarding this procedure? But I still hope that someone
from oVirt team can give an advice how to correct the database entries.
If necessary I would open a bug in Bugzilla.
Kind regards
Jan Siml
>> after a failed live storage migration (cause unknown) we have a
>> snapshot which is undeletable due to its status 'illegal' (as seen
>> in storage/snapshot tab). I have already found some bugs [1],[2],[3]
>> regarding this issue, but no way how to solve the issue within oVirt
> > 3.5.3.
>>
>> I have attached the relevant engine.log snippet. Is there any way to
>> do a live merge (and therefore delete the snapshot)?
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1213157
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1247377 links to [3]
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1247379 (no access)
>
> some additional informations. I have checked the images on both storages
> and verified the disk paths with virsh's dumpxml.
>
> a) The images and snapshots are on both storages.
> b) The images on source storage aren't used. (modification time)
> c) The images on target storage are used. (modification time)
> d) virsh -r dumpxml tells me disk images are located on _target_ storage.
> e) Admin interface tells me, that images and snapshot are located on
> _source_ storage, which isn't true, see b), c) and d).
>
> What can we do, to solve this issue? Is this to be corrected in database
> only?
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
------=_Part_286_211283766.1440765137323
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org=
/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns=3D"http://www.w3.org/1999/xhtml"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3DUTF-8=
"/>
<style type=3D"text/css">.mceResizeHandle {position: absolute;border: 1px
=
solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResi=
zeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid=
black}img.mceClonedResizable, table.mceClonedResizable {position: absolute=
;outline: 1px dashed black;opacity: .5;z-index: 10000}
</style></head><body style=3D""><div>got exactly the
same issue, with all n=
ice side effects like performance degradation. Until now i was not able to =
fix this, or to fool the engine somehow that it whould show the image as ok=
again and give me a 2nd chance to drop the snapshot.</div>
<div> </div>
<div>in some cases this procedure helped (needs 2nd storage domain)</div>
<div> </div>
<div>-> image live migration to a different storage domain (check which=
combinations are supported, iscsi -> nfs domain seems unsupported. isc=
si -> iscsi works)</div>
<div>-> snapshot went into ok state, and in ~50% i was able to drop the=
snapshot than. space had been reclaimed, so seems like this worked</div>
<div> </div>
<div> </div>
<div>other workaround is through exporting the image onto a nfs export doma=
in, here you can tell the engine to not export snapshots. after re-importin=
g everything is fine</div>
<div> </div>
<div> </div>
<div>the snapshot feature (live at least) should be avoided at all currentl=
y.... simply not reliable enaugh.</div>
<div> </div>
<div> </div>
<div>your way works, too. already did that, even it was a pita to figure ou=
t where to find what. this symlinking mess between /rhev /dev and /var/lib/=
libvirt is really awesome. not.</div>
<div> </div>
<div> </div>
<div>> Jan Siml &#60;jsiml(a)plusline.net&#62; hat am 28. August 2015
um =
12:56 geschrieben:<br>> <br>> <br>>
Hello,<br>> <br>> i=
f no one has an idea how to correct the Disk/Snapshot paths in Engine <br>&=
#62; database, I see only one possible way to solve the issue:<br>> <br=
> Stop the VM and copy image/meta files target storage to
source stora=
ge <br>> (the one where Engine thinks the files are
located). Start the=
VM.<br>> <br>> Any concerns regarding this procedure? But I
still =
hope that someone <br>> from oVirt team can give an advice how to corre=
ct the database entries. <br>> If necessary I would open a bug in Bugzi=
lla.<br>> <br>> Kind regards<br>>
<br>> Jan Siml<br>> <=
br>> >> after a failed live storage migration (cause unknown)
w=
e have a<br>> >> snapshot which is undeletable due to its
statu=
s 'illegal' (as seen<br>> >> in
storage/snapshot tab). =
I have already found some bugs [1],[2],[3]<br>> >> regarding
th=
is issue, but no way how to solve the issue within oVirt<br>> >
=
2; 3.5.3.<br>> >><br>> >> I
have attached the relev=
ant engine.log snippet. Is there any way to<br>> >> do a
live m=
erge (and therefore delete the snapshot)?<br>>
>><br>> >=
;> [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D1213157<br>>
&=
#62;> [2] https://bugzilla.redhat.com/show_bug.cgi?id=3D1247377 links t=
o [3]<br>> >> [3]
https://bugzilla.redhat.com/show_bug.cgi?id=
=3D1247379 (no access)<br>> ><br>> > some
additional inform=
ations. I have checked the images on both storages<br>> > and
verif=
ied the disk paths with virsh's dumpxml.<br>>
><br>> > =
a) The images and snapshots are on both storages.<br>> > b) The
ima=
ges on source storage aren't used. (modification time)<br>>
> c=
) The images on target storage are used. (modification time)<br>>
>=
d) virsh -r dumpxml tells me disk images are located on _target_ storage.<=
br>> > e) Admin interface tells me, that images and snapshot are lo=
cated on<br>> > _source_ storage, which isn't true, see b),
c) =
and d).<br>> ><br>> > What can we do, to solve
this issue? =
Is this to be corrected in database<br>> > only?<br>>
_________=
______________________________________<br>> Users mailing
list<br>>=
Users(a)ovirt.org<br>&#62; http://lists.ovirt.org/mailman/listinfo/users</di=
v></body></html>
------=_Part_286_211283766.1440765137323--