On Wed, Dec 23, 2015 at 03:15:50PM +0300, Roman Kagan wrote: > On Wed, Dec 23, 2015 at 10:47:22AM +0000, Daniel P. Berrange wrote: > > On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote: > > > As an alternative, can we introduce .bdrv_flock() in protocol drivers, > > > with > > > similar semantics to flock(2) or lockf(3)? That way all formats can > > > benefit, > > > and a program crash will automatically drop the lock. > > > > FWIW, the libvirt locking daemon (virtlockd) will already attempt to take > > out locks using fcntl()/lockf() on all disk images associated with a VM. > > Is it even possible without QEMU cooperating? In particular in complex > cases with e.g. backing chains? > > This was exactly the reason why we designed the "lock" option to take an > argument describing the locking mechanism to be used (see the tentative > patchset Denis posted in this thread). The only one currently > implemented is flock()-based; however it can be extended to other > mechanisms like network / cluster / SAN lock managers, etc. In > particular, it can be made to talk to virtlockd.
NB, libvirt generally considers QEMU to be untrustworthy, which is another reason why we use virtlockd to acquire the locks *prior* to granting QEMU any access to the file(s). On this basis we would not really trust QEMU to do acquire/release locks itself by talking to virtlockd. Indeed, we'd not really trust QEMU locking at all, no matter what mechanism it used - we want strong guarantee of locking regardless of whether QEMU is broken / compromised. 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 :|
