<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <style type="text/css">.mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle: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=""><div>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.</div>
<div>&#160;</div>
<div>in some cases this procedure helped (needs 2nd storage domain)</div>
<div>&#160;</div>
<div>-&#62; image live migration to a different storage domain (check which combinations are supported, iscsi -&#62; nfs domain seems unsupported. iscsi -&#62; iscsi works)</div>
<div>-&#62; 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>&#160;</div>
<div>&#160;</div>
<div>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</div>
<div>&#160;</div>
<div>&#160;</div>
<div>the snapshot feature (live at least) should be avoided at all currently.... simply not reliable enaugh.</div>
<div>&#160;</div>
<div>&#160;</div>
<div>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.</div>
<div>&#160;</div>
<div>&#160;</div>
<div>&#62; Jan Siml &#60;jsiml@plusline.net&#62; hat am 28. August 2015 um 12:56 geschrieben:<br>&#62; <br>&#62; <br>&#62; Hello,<br>&#62; <br>&#62; if 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>&#62; <br>&#62; Stop the VM and copy image/meta files target storage to source storage <br>&#62; (the one where Engine thinks the files are located). Start the VM.<br>&#62; <br>&#62; Any concerns regarding this procedure? But I still hope that someone <br>&#62; from oVirt team can give an advice how to correct the database entries. <br>&#62; If necessary I would open a bug in Bugzilla.<br>&#62; <br>&#62; Kind regards<br>&#62; <br>&#62; Jan Siml<br>&#62; <br>&#62; &#62;&#62; after a failed live storage migration (cause unknown) we have a<br>&#62; &#62;&#62; snapshot which is undeletable due to its status &#39;illegal&#39; (as seen<br>&#62; &#62;&#62; in storage/snapshot tab). I have already found some bugs [1],[2],[3]<br>&#62; &#62;&#62; regarding this issue, but no way how to solve the issue within oVirt<br>&#62; &#62; &#62; 3.5.3.<br>&#62; &#62;&#62;<br>&#62; &#62;&#62; I have attached the relevant engine.log snippet. Is there any way to<br>&#62; &#62;&#62; do a live merge (and therefore delete the snapshot)?<br>&#62; &#62;&#62;<br>&#62; &#62;&#62; [1] https://bugzilla.redhat.com/show_bug.cgi?id=1213157<br>&#62; &#62;&#62; [2] https://bugzilla.redhat.com/show_bug.cgi?id=1247377 links to [3]<br>&#62; &#62;&#62; [3] https://bugzilla.redhat.com/show_bug.cgi?id=1247379 (no access)<br>&#62; &#62;<br>&#62; &#62; some additional informations. I have checked the images on both storages<br>&#62; &#62; and verified the disk paths with virsh&#39;s dumpxml.<br>&#62; &#62;<br>&#62; &#62; a) The images and snapshots are on both storages.<br>&#62; &#62; b) The images on source storage aren&#39;t used. (modification time)<br>&#62; &#62; c) The images on target storage are used. (modification time)<br>&#62; &#62; d) virsh -r dumpxml tells me disk images are located on _target_ storage.<br>&#62; &#62; e) Admin interface tells me, that images and snapshot are located on<br>&#62; &#62; _source_ storage, which isn&#39;t true, see b), c) and d).<br>&#62; &#62;<br>&#62; &#62; What can we do, to solve this issue? Is this to be corrected in database<br>&#62; &#62; only?<br>&#62; _______________________________________________<br>&#62; Users mailing list<br>&#62; Users@ovirt.org<br>&#62; http://lists.ovirt.org/mailman/listinfo/users</div></body></html>