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
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 <> 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]
> >> [2] links to [3]
> >> [3] (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 mailing list

Reply via email to