Libguestfs - Sep 2017 - Re: [PATCH v3 0/6] launch: direct: Disable qemu locking when opening drives readonly.

On Wed, Sep 13, 2017 at 11:25:32AM +0300, Roman Kagan
wrote:
> On Tue, Sep 12, 2017 at 06:04:18PM +0100, Richard W.M. Jones wrote:
> > v2 -> v3:
> > 
> >  - I addressed everything that Pino mentioned last time.
> > 
> >  - It's tricky to get a stable run when multiple copies of qemu
are
> >    involved, because the same cache files get overwritten by parallel
> >    libguestfs.  So I changed the names of the cache files to include
> >    the qemu binary key (size, mtime), which removes this conflict.
> >    This is in new patch 4/6.
> 
> Sorry I must have missed the motivation part so could you please remind
> why locking needed to be turned off?
qemu 2.10 implements mandatory file locking, so if two instances of
qemu open the same file for writing you'll get an error:

  $ qemu-system-x86_64 -hda backing &      # works
  $ qemu-system-x86_64 -hda backing 
  qemu-system-x86_64: Failed to get "write" lock
  Is another process using the image?

So nothing wrong with that and it's an important mechanism to prevent
image corruption.  (Where two qemu instances actually need shared
write access you can use ‘share-rw=on’).

However the exclusive lock prevents libguestfs from *reading* from an
open disk image, eg. to do virt-df to monitor space or virt-tail to
monitor log files.  Such disk images are opened using the
guestfs_add_drive_opts readonly=true flag, which is implemented by
placing a qcow2 overlay on top of the disk image, the purpose of the
overlay being to take any writes and protect the underlying disk image
from being modified.

This kind of access is safe[1].  However qemu mandatory locking
prevents it by trying to acquire a lock on the backing file (because
in general terms qemu could write to the backing file eg if you
committed a snapshot, although libguestfs never does this).

So in the case where readonly=true, this patch series uses
file.locking=off to turn off locking on the backing file.

It doesn't affect the readonly=false case.  An exclusive lock is
acquired in this case, so you'll now not be able to corrupt a disk
which is in use, which is an advance.

We also have some tests (in tests/qemu) to ensure that qemu never does
any funny stuff like modifying a qcow2 file when it is opened
readonly.

Rich.

[1] Safe from the point of view that it won't ever modify the disk
image.  It's not guaranteed that libguestfs won't see strange
corruption, so users of this have to be prepared to retry operations
if they see errors.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v