[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening
Date: Wed, 11 May 2016 10:04:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]