Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening

[Kevin Wolf <kwolf@redhat.com>]

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