Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Jan 11, 2016 at 07:35:57PM +0100, Kevin Wolf wrote:
> Am 11.01.2016 um 18:58 hat Daniel P. Berrange geschrieben:
> > On Mon, Jan 11, 2016 at 06:31:06PM +0100, Kevin Wolf wrote:
> > > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben:
> > > > From: Olga Krishtal <okrishtal@virtuozzo.com>
> > > > 
> > > > While opening the image we want to be sure that we are the
> > > > one who works with image, anf if it is not true -
> > > > opening the image for writing should fail.
> > > > 
> > > > There are 2 ways at the moment: no lock at all and lock the file
> > > > image.
> > > > 
> > > > Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
> > > > Signed-off-by: Denis V. Lunev <den@openvz.org>
> > > > CC: Kevin Wolf <kwolf@redhat.com>
> > > > CC: Max Reitz <mreitz@redhat.com>
> > > > CC: Eric Blake <eblake@redhat.com>
> > > > CC: Fam Zheng <famz@redhat.com>
> > > 
> > > As long as locking is disabled by default, it's useless and won't
> > > prevent people from corrupting their images. These corruptions happen
> > > exactly because people don't know how to use qemu properly. You can't
> > > expect them to enable locking manually.
> > > 
> > > Also, you probably need to consider bdrv_reopen() and live migration.
> > > I think live migration would be blocked if source and destination both
> > > see the lock; which is admittedly less likely than with the qcow2 patch
> > > (and generally a problem of this series), but with localhost migration
> > > and potentially with some NFS setups it can be the case.
> > 
> > Note that when libvirt does locking it will release locks when a VM
> > is paused, and acquire locks prior to resuming CPUs. This allows live
> > migration to work because you never have CPUs running on both src + dst
> > at the same time. This does mean that libvirt does not allow QEMU to
> > automatically re-start CPUs when migration completes, as it needs to
> > take some action to acquire locks before allowing the dst to start
> > running again.
> 
> This assumes that block devices can only be written to if CPUs are
> running. In the days of qemu 0.9, this was probably right, but with
> things like block jobs and built-in NBD servers, I wouldn't be as sure
> these days.

True, libvirt knows when it is using block jobs & NBD servers, so it
should not be difficult to address this.

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