From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0P8R-0001hq-6Y for qemu-devel@nongnu.org; Wed, 11 May 2016 04:04:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0P8P-0000Xn-NU for qemu-devel@nongnu.org; Wed, 11 May 2016 04:04:47 -0400 Date: Wed, 11 May 2016 16:04:40 +0800 From: Fam Zheng Message-ID: <20160511080440.GA12252@ad.usersys.redhat.com> References: <20160510092338.GG13377@redhat.com> <20160510093514.GH4921@noname.str.redhat.com> <20160510094310.GH13377@redhat.com> <20160510100706.GJ4921@noname.str.redhat.com> <20160510101612.GY1683@redhat.com> <20160510110849.GK4921@noname.str.redhat.com> <20160510114615.GZ1683@redhat.com> <20160510120102.GM4921@noname.str.redhat.com> <20160510121130.GA1683@redhat.com> <20160510122209.GJ13377@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160510122209.GJ13377@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , rjones@redhat.com Cc: Kevin Wolf , qemu-block@nongnu.org, Jeff Cody , Markus Armbruster , qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, den@openvz.org, Max Reitz , John Snow 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. Fam > > 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. > > 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 :|