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