On Wed, May 11, 2016 at 04:04:40PM +0800, Fam Zheng wrote: > On Tue, 05/10 13:22, Daniel P. Berrange wrote: > > 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). > > It sounds you are happy with either way but actually this series does both. > So, > would it be okay for libguestfs if we go for "lock r/o VMs by default and > provide nolock flag"? It would then have the best default for non-libguestfs > users.
Yes, and libguestfs will always pass the nolock flag for readonly disks. Another question is whether doing: qemu-img create -b disk.img -f qcow2 overlay.qcow2 is permitted, since that is the first command that libguestfs issues when opening a disk read-only (where disk.img could be a live VM in the case we're talking about). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
