4:39 p.m.
------=_Part_292_1575779874.1440769177725
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Jan Siml <jsiml(a)plusline.net> hat am 28. August 2015 um 15:15
geschrieben:
Hello Juergen,
> 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
okay, seems interesting. But I'm afraid of not knowing which image files
Engine uses when live migration is demanded. If Engine uses the ones
which are actually used and updates the database afterwards -- fine. But
if the images are used that are referenced in Engine database, we will
take a journey into the past.
knocking on wood. so far no problems, and i used this way for sure 50 times +
in cases where the live merge failed, offline merging worked in another 50%.
those which fail offline, too went back to illegal snap state
> 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?
Kind regards
Jan Siml
------=_Part_292_1575779874.1440769177725
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><br>>
Jan Siml <jsiml@plusline=
.net> hat am 28. August 2015 um 15:15 geschrieben:<br>>
<br>> <=
br>> Hello Juergen,<br>> <br>> > got
exactly the same issue=
, with all nice side effects like performance<br>> > degradation.
U=
ntil now i was not able to fix this, or to fool the engine<br>> >
s=
omehow that it whould show the image as ok again and give me a 2nd<br>>=
> chance to drop the snapshot.<br>> > in some cases this
proce=
dure helped (needs 2nd storage domain)<br>> > -> image live
mig=
ration to a different storage domain (check which<br>> >
combinatio=
ns are supported, iscsi -> nfs domain seems unsupported.
iscsi<br>>=
> -> iscsi works)<br>> > -> snapshot went
into ok stat=
e, and in ~50% i was able to drop the<br>> > snapshot than. space
h=
ad been reclaimed, so seems like this worked<br>> <br>> okay,
seems=
interesting. But I'm afraid of not knowing which image files
<br>>=
Engine uses when live migration is demanded. If Engine uses the ones <br>&=
#62; which are actually used and updates the database afterwards -- fine. B=
ut <br>> if the images are used that are referenced in Engine database,=
we will <br>> take a journey into the past.</div>
<div> </div>
<div>knocking on wood. so far no problems, and i used this way for sure 50 =
times +</div>
<div> </div>
<div>in cases where the live merge failed, offline merging worked in anothe=
r 50%. those which fail offline, too went back to illegal snap state</div>
<div><br>> <br>> > other workaround is through
exporting the im=
age onto a nfs export<br>> > domain, here you can tell the engine
t=
o not export snapshots. after<br>> > re-importing everything is
fin=
e<br>> > the snapshot feature (live at least) should be avoided at
=
all<br>> > currently.... simply not reliable
enaugh.<br>> >=
your way works, too. already did that, even it was a pita to figure out<br=
> > where to find what. this symlinking mess between
/rhev /dev an=
d<br>> > /var/lib/libvirt is really awesome.
not.<br>> > &#=
62; Jan Siml &#60;jsiml(a)plusline.net&#62; hat am 28. August 2015 um 12:56<b=
r>> > geschrieben:<br>> >
><br>> > ><br>=
2; > > Hello,<br>> > ><br>>
> > if no one h=
as an idea how to correct the Disk/Snapshot paths in Engine<br>> >
=
> database, I see only one possible way to solve the issue:<br>>
&#=
62; ><br>> > > Stop the VM and copy image/meta files
target=
storage to source storage<br>> > > (the one where Engine
think=
s 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 correct
the=
database entries.<br>> > > If necessary I would open a bug
in =
Bugzilla.<br>> > ><br>> > >
Kind regards<br>> &=
#62; ><br>> > > Jan Siml<br>>
> ><br>> >=
; > >> after a failed live storage migration (cause unknown) we=
have a<br>> > > >> snapshot which is
undeletable due t=
o its status 'illegal' (as seen<br>> > >
>> in =
storage/snapshot tab). I have already found some bugs [1],[2],[3]<br>> =
> > >> regarding this issue, but no way how to solve the
is=
sue within oVirt<br>> > > > >
3.5.3.<br>> > =
2; >><br>> > > >> I have
attached the relevant =
engine.log snippet. Is there any way to<br>> > >
>> do =
a live merge (and therefore delete the snapshot)?<br>> > >
>=
;><br>> > > >> [1]
https://bugzilla.redhat.com/show=
_bug.cgi?id=3D1213157<br>> > > >> [2]
https://bugzilla.=
redhat.com/show_bug.cgi?id=3D1247377 links to [3]<br>> > >
>=
;> [3] https://bugzilla.redhat.com/show_bug.cgi?id=3D1247379 (no access=
)<br>> > > ><br>> > >
> some additional inf=
ormations. I have checked the images on both<br>> >
storages<br>=
2; > > > and verified the disk paths with virsh's
dumpxml.<=
br>> > > ><br>> > >
> a) The images and sna=
pshots are on both storages.<br>> > > > b) The
images on so=
urce storage aren't used. (modification time)<br>> >
> >=
; c) The images on target storage are used. (modification time)<br>>
&#=
62; > > d) virsh -r dumpxml tells me disk images are located on _ta=
rget_<br>> > storage.<br>> > >
> e) Admin interface=
tells me, that images and snapshot are located on<br>> > >
=
2; _source_ storage, which isn't true, see b), c) and d).<br>>
>=
; > ><br>> > > > What can we do, to
solve this issu=
e? Is this to be corrected in<br>> > database<br>>
> > =
> only?<br>> <br>> Kind regards<br>>
<br>> Jan Siml</di=
v></body></html>
------=_Part_292_1575779874.1440769177725--