On Mon, Apr 18, 2016 at 09:04:19AM +0100, 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.
Have you ever considered integration with the QEMU NBD server. We
don't have APIs for enabling it explicitly in libvirt, but it strikes
me that it could be ideally suited for your needs.
eg a hypothetical libvirt command to export a disk via NBD:
virsh dom-export-disk myguest --readonly vda1 localhost 9000
qemu-img create -f qcow2 -b nbd:localhost:9000 tmp-overlay.img
...do stuff...
virsh dom-unexport-disk myguest vda1
Or to make cleanup easier, perhaps there's a way to tell QEMU
to close its NBD server after it has had 1 client connection.
With this approach, you wouldn't need to take any lock on the
underlying real image.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
