On Wed, May 11, 2016 at 10:04:12AM +0200, Markus Armbruster wrote: > "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.
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 :|
