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 <okrish...@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 <okrish...@virtuozzo.com> > > Signed-off-by: Denis V. Lunev <d...@openvz.org> > > CC: Kevin Wolf <kw...@redhat.com> > > CC: Max Reitz <mre...@redhat.com> > > CC: Eric Blake <ebl...@redhat.com> > > CC: Fam Zheng <f...@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. 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 :|
