<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 3:33 PM, Jordan Pittier <span dir="ltr"><<a href="mailto:jordan.pittier@scality.com" target="_blank">jordan.pittier@scality.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div>On Thu, Apr 9, 2015 at 6:10 PM, Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> wrote:<br></div></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 04/08/2015 11:22 PM, Deepak Shetty wrote:<br>
> + [Cinder] and [Tempest] in the $subject since this affects them too<br>
><br>
> On Thu, Apr 9, 2015 at 4:22 AM, Eric Blake <<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>> wrote:<br>
><br>
>> 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<br>
>> which<br>
>>> needs domain to be active.<br>
>><br>
>> 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>
>><br>
><br>
> Is there a bug/feature already opened for this ?<br>
<br>
</span>Libvirt has this bug: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=987719" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=987719</a><br>
which tracks generic ability of libvirt to delete snapshots; ideally,<br>
the code to manage snapshots will work for both online and persistent<br>
offline guests, but it may result in splitting the work into multiple bugs.<br>
<span><br></span></blockquote><div> </div></span><div>I can't access this bug report, it seems "private", I need to authenticate.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><span>
> I didn't understand much<br>
> on what you<br>
> mean by re-connectible unix socket :)... are you hinting that qemu-img<br>
> doesn't have<br>
> ability to attach to a qemu / VM process for long time over unix socket ?<br>
<br>
</span>For online guest control, libvirt normally creates a Unix socket, then<br>
starts qemu with its -qmp monitor pointing to that socket.  That way, if<br>
libvirtd goes away and then restarts, it can reconnect as a client to<br>
the existing socket file, and qemu never has to know that the person on<br>
the other end changed.  With that QMP monitor, libvirt can query qemu's<br>
current state at will, get event notifications when long-running jobs<br>
have finished, and issue commands to terminate long-running jobs early,<br>
even if it is a different libvirtd issuing a later command than the one<br>
that started the command.<br>
<br>
qemu-img, on the other hand, only has the -p option or SIGUSR1 signal<br>
for outputting progress to stderr on a long-running operation (not the<br>
most machine-parseable), but is not otherwise controllable.  It does not<br>
have a management connection through a Unix socket.  I guess in thinking<br>
about it a bit more, a Unix socket is not essential; as long as the old<br>
libvirtd starts qemu-img in a manner that tracks its pid and collects<br>
stderr reliably, then restarting libvirtd can send SIGUSR1 to the pid<br>
and track the changes to stderr to estimate how far along things are.<br>
<br>
Also, the idea has been proposed that qemu-img is not necessary; libvirt<br>
could use qemu -M none to create a dummy machine with no CPUs and JUST<br>
disk images, and then use the qemu QMP monitor as usual to perform block<br>
operations on those disks by reusing the code it already has working for<br>
online guests.  But even this approach needs coding into libvirt.<br>
<div><div><br>
--<br>
Eric Blake   eblake redhat com    <a href="tel:%2B1-919-301-3266" value="+19193013266" target="_blank">+1-919-301-3266</a><br>
Libvirt virtualization library <a href="http://libvirt.org" target="_blank">http://libvirt.org</a><br>
<br>
</div></div><br></div></div><span class="">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><div class="gmail_extra"><br></div>Hi,<div>I'd like to progress on this issue, so I will spend some time on it.</div><div><br></div><div>Let's recap. The issue is "deleting a Cinder snapshot that was created during an Nova Instance snapshot (booted from a cinder volume) doesn't work when the original Nova Instance is stopped". This bug only arises when a Cinder driver uses the feature called "QEMU Assisted Snapshots"/live-snapshot. (currently only GlusterFS, but soon generic NFS when <a href="https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots" target="_blank">https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots</a> gets in).</div><div><br></div><div>This issue is triggered by the Tempest scenario "test_volume_boot_pattern". This scenario:</div><div>[does some stuff]</div><div>1) Creates a cinder volume from an Cirros Image</div><div>2) Boot a Nova Instance on the volume</div><div>3) Make a snapshot of this instance (which creates a cinder snapshot because the instance was booted from a volume), using the feature QEMU Assisted Snapshots</div><div>[do some other stuff]</div><div>4) stop the instance created in step 2 then delete the snapshot created in step 3.</div><div><br></div><div>The deletion of snapshot created in step 3 fails because Nova wants libvirt to do a <span style="font-size:12.8000001907349px">blockRebase (see <a href="https://github.com/openstack/nova/blob/68f6f080b2cddd3d4e97dc25a98e0c84c4979b8a/nova/virt/libvirt/driver.py#L1920" target="_blank">https://github.com/openstack/nova/blob/68f6f080b2cddd3d4e97dc25a98e0c84c4979b8a/nova/virt/libvirt/driver.py#L1920</a>)</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">For reference, there's a bug targeting Cinder for this : <a href="https://bugs.launchpad.net/cinder/+bug/1444806" target="_blank">https://bugs.launchpad.net/cinder/+bug/1444806</a> </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">What I'd like to do, but I am asking your advice first is:</span></div><div><span style="font-size:12.8000001907349px">Just before doing the call to </span><span style="font-size:12.8000001907349px">virt_dom.blockRebase(), check if the domain is running, and if not call "qemu-img rebase -b $rebase_base rebase_disk". (this idea was brought up by </span>Eric Blake in the previous reply).</div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Questions:</span></div><div><span style="font-size:12.8000001907349px">Is it safe to do so ?</span></div><div><span style="font-size:12.8000001907349px">Is it the right approach ? (given that I don't really want to wait for libvirt to support blockRebase on offline domain)</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Thanks a lot !</span></div><span class=""><font color="#888888"><div><span style="font-size:12.8000001907349px">Jordan</span></div></font></span></div></div></blockquote><div><br></div><div>I went ahead and proposed the following patch : <a href="https://review.openstack.org/#/c/192736">https://review.openstack.org/#/c/192736</a> </div></div><br></div></div>