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

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> 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.