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