From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0Qz9-0006K5-Ts for qemu-devel@nongnu.org; Wed, 11 May 2016 06:03:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0Qz4-0004Oi-LE for qemu-devel@nongnu.org; Wed, 11 May 2016 06:03:18 -0400 Date: Wed, 11 May 2016 12:03:04 +0200 From: Kevin Wolf Message-ID: <20160511100304.GA4524@noname.str.redhat.com> References: <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> <20160511080440.GA12252@ad.usersys.redhat.com> <20160511092820.GD1683@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160511092820.GD1683@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: "Richard W.M. Jones" Cc: Fam Zheng , "Daniel P. Berrange" , 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 Am 11.05.2016 um 11:28 hat Richard W.M. Jones geschrieben: > > 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). I think qemu-img has a few special cases where the lock can be ignored as well. Opening the backing file to query its size could be one of them; but if you pass a size, qemu-img doesn't even need to open it. 'qemu-img info' could be another thing that is reasonable enough on an image that is in use. Kevin