Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, May 11, 2016 at 10:04:12AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> >> At no point did I say that it was safe to use libguestfs on live VMs
> >> or that you would always get consistent data out.
> >> 
> >> But the fact that it can fail is understood, the chance of failure is
> >> really tiny (it has literally only happened twice that I've read
> >> corrupted data, in years of daily use), and the operation is very
> >> useful.
> >> 
> >> So I think this patch series should either not lock r/o VMs, or should
> >> add a nolock flag to override the locking (which libguestfs will
> >> always use).
> >
> > If QEMU locks r/o disks, then libvirt would likely end up setting the
> > "nolock" flag unconditionally too, in order to avoid breaking libguestfs
> > and other application usage of libvirt.
> 
> Could a QEMU + libvirt together provide both safe and unsafe read-only
> access?  Safe means you get consistent data.  Unsafe means you're taking
> your chances.
> 
> Libguestfs could then use unsafe if the user asks for it.  Or even by
> default; that's really libguesfs's business.
> 
> Backward compatibility may complicate things, but getting into a
> reasonable state is sometimes worth a lengthy and somewhat messy
> transition.

We would have to use 'nolock' by default, and provide apps an opt-in
config flag to request locking of r/o images if they wanted it.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|