<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-15 15:16 GMT+02:00 Hitoshi Mitake <span dir="ltr"><<a href="mailto:mitake.hitoshi@gmail.com" target="_blank">mitake.hitoshi@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
As Valerio points, this problem is not only related to the VDI locking<br>
feature. For avoiding this problem, we need to run "dog vdi check"<br>
after sudden death of QEMU process or node.<br></blockquote><div><br></div><div>Ok, that's good to know.<br><br></div><div>So a sudden death of qemu will just leave the lock that may be removed by vdi check or a new command if required.<br>
</div><div>So, generally speaking: if I try to run a guest and qemu  exits with an error complaining about the lock, it means another process is currently using it;<br></div><div>if I don't find this process, it means a qemu process has die previously and I need to run vdi check.<br>
<br></div><div>That sounds more safe than before because I may have run the guest without knowing the vdi may be in an inconsistent state because of a crash I didn't know of.<br><br></div><div>The down side of is that the bigger the vdi, the longer the time for the check, but that is unrelated to the vdi locking patch.<br>
<br></div><div>One more question:<br></div><div>kill -15 vs kill -9:<br></div><div>Is kill -15 going to terminate qemu in a "sweet" way, so it flushed it's data and remove the lock before dieing? Or does it have the same effect (from the lock point of view) of a kill -15?<br>
</div></div></div></div>