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

[Fam Zheng]

On Mon, 04/18 09:04, Richard W.M. Jones wrote:
> 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.

I'm not sure that is what we want to support. The image is being read-write
open by the VM, any other accessing is a bad idea.

Fam

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