qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening
Date: Tue, 10 May 2016 14:01:02 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 10.05.2016 um 13:46 hat Richard W.M. Jones geschrieben:
> On Tue, May 10, 2016 at 01:08:49PM +0200, Kevin Wolf wrote:
> > Are you saying that libguestfs only allows operations like df on live
> > images, but not e.g. copying files out of the VM?
> [...]
> 
> virt-copy-out will let you copy out files from a live VM.
> 
> There's no difference between "safe" and "unsafe" operations, because
> (a) it depends on unknowable information about the guest -- it's safe
> to read (even write) a filesystem if it's not mounted by the guest,
> and (b) even reading a superblock field from an in-use mounted
> filesystem is subject to an unlikely but possible race.

The consequences of a failure are different. Specifically, in the quote
that you stripped from this email, you said as a justification for
ignoring the possible problems:

> 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.

Creating corrupted copies of data is much worse than wrong stats in a
virt-df result, in my opinion.

> Users of libguestfs on live VMs just have to be aware of this, and we
> make them aware over and over again of the potential problems.

The correct way to make them aware is requiring something like a --force
flag. Just writing it in the documentation is not much more than an
excuse to tell the users that it was their own fault.

> Importantly, readonly access won't result in corrupt filesystems in
> the live VM.

Yes, it only results in corrupt data in the copy. Is that much better?

> I'm much more interested in stopping people from writing to live VMs.
> That is a serious problem, results in unrecoverable filesystems and
> near-100% certain data loss [especially with journalled fses], and is
> something that has no (or very very few) valid use cases.  It's also
> something which only qemu is in a position to properly protect
> against.

Nobody is saying that we shouldn't protect against writing to live VMs.

We're discussing that you are objecting to protecting users against
reading from live VMs, which may not be quite as disastrous in many
cases, but can result in corruption, too. And here as well only qemu is
in the position to properly protect against it.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]