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/
