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