<!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><br>&#62; Jan Siml &#60;jsiml@plusline.net&#62; hat am 28. August 2015 um 16:47 geschrieben:<br>&#62; <br>&#62; <br>&#62; Hello,<br>&#62; <br>&#62; &#62; &#62; &#62; got exactly the same issue, with all nice side effects like performance<br>&#62; &#62; &#62; &#62; degradation. Until now i was not able to fix this, or to fool the<br>&#62; &#62; engine<br>&#62; &#62; &#62; &#62; somehow that it whould show the image as ok again and give me a 2nd<br>&#62; &#62; &#62; &#62; chance to drop the snapshot.<br>&#62; &#62; &#62; &#62; in some cases this procedure helped (needs 2nd storage domain)<br>&#62; &#62; &#62; &#62; -&#62; image live migration to a different storage domain (check which<br>&#62; &#62; &#62; &#62; combinations are supported, iscsi -&#62; nfs domain seems unsupported.<br>&#62; &#62; iscsi<br>&#62; &#62; &#62; &#62; -&#62; iscsi works)<br>&#62; &#62; &#62; &#62; -&#62; snapshot went into ok state, and in ~50% i was able to drop the<br>&#62; &#62; &#62; &#62; snapshot than. space had been reclaimed, so seems like this worked<br>&#62; &#62; &#62;<br>&#62; &#62; &#62; okay, seems interesting. But I&#39;m afraid of not knowing which image files<br>&#62; &#62; &#62; Engine uses when live migration is demanded. If Engine uses the ones<br>&#62; &#62; &#62; which are actually used and updates the database afterwards -- fine. But<br>&#62; &#62; &#62; if the images are used that are referenced in Engine database, we will<br>&#62; &#62; &#62; take a journey into the past.<br>&#62; &#62; knocking on wood. so far no problems, and i used this way for sure 50<br>&#62; &#62; times +<br>&#62; <br>&#62; This doesn&#39;t work. Engine creates the snapshots on wrong storage (old) <br>&#62; and this process fails, cause the VM (qemu process) uses the images on <br>&#62; other storage (new).</div>
<div>&#160;</div>
<div>sounds like there are some other problems in your case, wrong db entries image -&#62; snapshot? i didnt investigate further in the vm which failed this process, i directly went further and exported them</div>
<div><br>&#62; <br>&#62; &#62; in cases where the live merge failed, offline merging worked in another<br>&#62; &#62; 50%. those which fail offline, too went back to illegal snap state<br>&#62; <br>&#62; I fear offline merge would cause data corruption. Because if I shut down <br>&#62; the VM, the information in Engine database is still wrong. Engine thinks <br>&#62; image files and snapshots are on old storage. But VM has written to the <br>&#62; equal named image files on new storage. And offline merge might use the <br>&#62; &#34;old&#34; files on old storage.</div>
<div>&#160;</div>
<div>than your initial plan is an alternative. you use thin or raw on what kind of storage domain? but like said, manually processing is a pita due to the symlink mess.</div>
<div><br>&#62; <br>&#62; &#62; &#62; &#62; other workaround is through exporting the image onto a nfs export<br>&#62; &#62; &#62; &#62; domain, here you can tell the engine to not export snapshots. after<br>&#62; &#62; &#62; &#62; re-importing everything is fine<br>&#62; <br>&#62; Same issue as with offline merge.<br>&#62; <br>&#62; Meanwhile I think, we need to shut down the VM, copy the image files <br>&#62; from one storage (qemu has used before) to the other storage (the one <br>&#62; Engine expects) and pray while starting the VM again.<br>&#62; <br>&#62; &#62; &#62; &#62; the snapshot feature (live at least) should be avoided at all<br>&#62; &#62; &#62; &#62; currently.... simply not reliable enaugh.<br>&#62; &#62; &#62; &#62; your way works, too. already did that, even it was a pita to figure out<br>&#62; &#62; &#62; &#62; where to find what. this symlinking mess between /rhev /dev and<br>&#62; &#62; &#62; &#62; /var/lib/libvirt is really awesome. not.<br>&#62; &#62; &#62; &#62; &#62; Jan Siml &#60;jsiml@plusline.net&#62; hat am 28. August 2015 um 12:56<br>&#62; &#62; &#62; &#62; geschrieben:<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; Hello,<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; if no one has an idea how to correct the Disk/Snapshot paths in<br>&#62; &#62; Engine<br>&#62; &#62; &#62; &#62; &#62; database, I see only one possible way to solve the issue:<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; Stop the VM and copy image/meta files target storage to source<br>&#62; &#62; storage<br>&#62; &#62; &#62; &#62; &#62; (the one where Engine thinks the files are located). Start the VM.<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; Any concerns regarding this procedure? But I still hope that someone<br>&#62; &#62; &#62; &#62; &#62; from oVirt team can give an advice how to correct the database<br>&#62; &#62; entries.<br>&#62; &#62; &#62; &#62; &#62; If necessary I would open a bug in Bugzilla.<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; Kind regards<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; Jan Siml<br>&#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; after a failed live storage migration (cause unknown) we have a<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; snapshot which is undeletable due to its status &#39;illegal&#39; (as seen<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; in storage/snapshot tab). I have already found some bugs<br>&#62; &#62; [1],[2],[3]<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; regarding this issue, but no way how to solve the issue within<br>&#62; &#62; oVirt<br>&#62; &#62; &#62; &#62; &#62; &#62; &#62; 3.5.3.<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62;<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; I have attached the relevant engine.log snippet. Is there any<br>&#62; &#62; way to<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; do a live merge (and therefore delete the snapshot)?<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62;<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; [1] https://bugzilla.redhat.com/show_bug.cgi?id=1213157<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; [2] https://bugzilla.redhat.com/show_bug.cgi?id=1247377 links<br>&#62; &#62; to [3]<br>&#62; &#62; &#62; &#62; &#62; &#62;&#62; [3] https://bugzilla.redhat.com/show_bug.cgi?id=1247379 (no<br>&#62; &#62; access)<br>&#62; &#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; &#62; some additional informations. I have checked the images on both<br>&#62; &#62; &#62; &#62; storages<br>&#62; &#62; &#62; &#62; &#62; &#62; and verified the disk paths with virsh&#39;s dumpxml.<br>&#62; &#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; &#62; a) The images and snapshots are on both storages.<br>&#62; &#62; &#62; &#62; &#62; &#62; b) The images on source storage aren&#39;t used. (modification time)<br>&#62; &#62; &#62; &#62; &#62; &#62; c) The images on target storage are used. (modification time)<br>&#62; &#62; &#62; &#62; &#62; &#62; d) virsh -r dumpxml tells me disk images are located on _target_<br>&#62; &#62; &#62; &#62; storage.<br>&#62; &#62; &#62; &#62; &#62; &#62; e) Admin interface tells me, that images and snapshot are<br>&#62; &#62; located on<br>&#62; &#62; &#62; &#62; &#62; &#62; _source_ storage, which isn&#39;t true, see b), c) and d).<br>&#62; &#62; &#62; &#62; &#62; &#62;<br>&#62; &#62; &#62; &#62; &#62; &#62; What can we do, to solve this issue? Is this to be corrected in<br>&#62; &#62; &#62; &#62; database<br>&#62; &#62; &#62; &#62; &#62; &#62; only?<br>&#62; <br>&#62; Kind regards<br>&#62; <br>&#62; Jan Siml</div></body></html>