<div dir="ltr">+ [Cinder] and [Tempest] in the $subject since this affects them too<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 4:22 AM, Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/08/2015 12:01 PM, Deepak Shetty wrote:<br>
><br>
> Questions:<br>
><br>
> 1) Is this a valid scenario being tested ? Some say yes, I am not sure,<br>
> since the test makes sure that instance is OFF before snap is deleted and<br>
> this doesn't work for fs-backed drivers as they use hyp assisted snap which<br>
> needs domain to be active.<br>
<br>
</span>Logically, it should be possible to delete snapshots when a domain is<br>
off (qemu-img can do it, but libvirt has not yet been taught how to<br>
manage it, in part because qemu-img is not as friendly as qemu in having<br>
a re-connectible Unix socket monitor for tracking long-running progress).<br></blockquote><div><br></div><div>Is there a bug/feature already opened for this ? I didn't understand much on what you <br>mean by re-connectible unix socket :)... are you hinting that qemu-img doesn't have<br>ability to attach to a qemu / VM process for long time over unix socket ?<br><br>Looks like many believe that this should be a valid scenario but it currently breaks the<br>fs-backed cinder drivers as the testcase proves.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
> 2) If this is valid scenario, then it means libvirt.py in nova should be<br>
> modified NOT to raise error, but continue with the snap delete (as if<br>
> volume was not attached) and take care of the dom xml (so that domain is<br>
> still bootable post snap deletion), is this the way to go ?<br>
<br>
</span>Obviously, it would be nice to get libvirt to support offline snapshot<br>
deletion, but until then, upper layers will have to work around<br>
libvirt's shortcomings.  I don't know if that helps answer your<br>
questions, though.<br></blockquote><div><br></div><div>Thanks, it does in a way.<br><br></div><div>Q to Tempest folks,<br>    Given that libvirt doesn't support this scenario yet, can fs-backed cinder drivers affected<br></div><div>by this be able to skip this testcase (using storage_protocol = 'glusterfs' for <br>gluster case) until either this is supported by libvirt or some workaround in Nova is<br></div><div>decided upon ?<br><br></div><div>Appreciate your inputs.<br></div><div><br></div><div>thanx,<br></div><div>deepak<br><br></div></div></div></div></div>