From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b05XD-0007oO-0F for qemu-devel@nongnu.org; Tue, 10 May 2016 07:09:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b05XA-000830-B2 for qemu-devel@nongnu.org; Tue, 10 May 2016 07:09:01 -0400 Date: Tue, 10 May 2016 13:08:49 +0200 From: Kevin Wolf Message-ID: <20160510110849.GK4921@noname.str.redhat.com> References: <1462848659-28659-1-git-send-email-famz@redhat.com> <20160510081425.GV1683@redhat.com> <20160510084303.GB28935@redhat.com> <20160510085041.GC13377@redhat.com> <20160510091422.GG4921@noname.str.redhat.com> <20160510092338.GG13377@redhat.com> <20160510093514.GH4921@noname.str.redhat.com> <20160510094310.GH13377@redhat.com> <20160510100706.GJ4921@noname.str.redhat.com> <20160510101612.GY1683@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160510101612.GY1683@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: "Daniel P. Berrange" , Fam Zheng , 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 10.05.2016 um 12:16 hat Richard W.M. Jones geschrieben: > On Tue, May 10, 2016 at 12:07:06PM +0200, Kevin Wolf wrote: > > I'm surprised how low the standards seem to be when we're talking about > > data integrity. If occasionally losing data is okay, the qemu block > > layer could be quite a bit simpler. > > I welcome this patch because it fixes a real data integrity issue > which we've seen in the field: people using guestfish (in write mode) > on live VMs. Yes, people writing to live disks is a very real issue. They don't only use guestfish for it, but also qemu-img (e.g. taking snapshots), and these are the cases that become visible on the qemu mailing list. But if you imply that the read-only case isn't real, I have to disagree. Sometimes people also try to copy data out from a live VM with qemu-img convert, and while this seems to succeed, they may actually have produced a corrupt copy. This is why I want to protect the read-only case as well. > We try our very best to prevent this happening -- for example if you > use guestfish via libvirt, it will check if the VM is live and refuse > access. Though this is not and cannot be bulletproof (since someone > can start a VM up after we have opened it). We also have prominent > warnings in the manual and in the FAQ about this. > > However _reading_ disks doesn't corrupt live VMs. The worst that > happens is guestfish will error out or you'll see some inconsistent > stats from virt-df. Are you saying that libguestfs only allows operations like df on live images, but not e.g. copying files out of the VM? Because if copying data out was allowed, I'd suspect that people would use it on live VMs and would be surprised if they didn't get what they expected (which they often only notice when it's too late). I guess you're right that we can tolerate some df command not being 100% sure to return the right numbers, but it's a very special case and I think it's not demanding too much if you need to pass a lock-override flag when you do something like this, when this can protect people against accidentally creating corrupted copies. > None of this has anything to do with data integrity in the qemu block > layer, and no one is arguing that it should be weakened. We're talking about real data corruption in both cases. Kevin