Re: [Qemu-devel] [PATCH for-2.7 v2 05/17] raw-posix: Implement .bdrv_lockf

[Richard W.M. Jones]

On Mon, Apr 18, 2016 at 09:10:36AM +0800, Fam Zheng wrote:
> On Sun, 04/17 20:27, Richard W.M. Jones wrote:
> > On Fri, Apr 15, 2016 at 11:27:55AM +0800, Fam Zheng wrote:
> > > virtlockd in libvirt locks the first byte, we lock byte 1 to avoid
> > > the intervene.
> > > +static int raw_lockf(BlockDriverState *bs, BdrvLockfCmd cmd)
> > > +{
> > > +
> > > +    BDRVRawState *s = bs->opaque;
> > > +    int ret;
> > > +    struct flock fl = (struct flock) {
> > > +        .l_whence  = SEEK_SET,
> > > +        /* Locking byte 1 avoids interfereing with virtlockd. */
> > > +        .l_start = 1,
> > > +        .l_len = 1,
> > > +    };
> > > +
> > > +    switch (cmd) {
> > > +    case BDRV_LOCKF_RWLOCK:
> > > +        fl.l_type = F_WRLCK;
> > > +        break;
> > > +    case BDRV_LOCKF_ROLOCK:
> > > +        fl.l_type = F_RDLCK;
> > > +        break;
> > > +    case BDRV_LOCKF_UNLOCK:
> > > +        fl.l_type = F_UNLCK;
> > > +        break;
> > 
> > My understanding is this prevents libguestfs from working on live disk
> > images -- we want to be able to read live disk images (using a
> > writable overlay and the real disk image as a read-only backing file).
> 
> Do you lock the live image or the backing file?

At the moment we don't need to do anything, but we do have the problem
that if someone uses libguestfs in write mode on a live image, then
obviously they end up with a corrupted guest.

However in this email I'm talking about using libguestfs in
"read-only" mode on a live guest, which is a completely different
thing, and should not be prevented.

My assumption [with this patch applied] is the live image (being live)
is locked by some other qemu.

Now libguestfs creates a temporary overlay with the live image as
backing, using a command similar to:

  qemu-img create -f qcow2 -b live.img tmp-overlay.img

and opens 'tmp-overlay.img'.  But since the live image has an
exclusive lock, the open will *fail*, and that is a problem.

> If not, you can just read/write as before, as what the -L option
> does in this series. Otherwise, you should use an RO lock on the
> backing image, which still works.

fcntl-locks don't allow a shared lock to share with an exclusive lock.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/