On Tue, Oct 25, 2016 at 03:09:51PM +0800, Fam Zheng wrote: > On Mon, 10/24 12:11, Kevin Wolf wrote: > > Am 22.10.2016 um 03:00 hat Max Reitz geschrieben: > > > <parenthesis> > > > > > > I personally still don't like making locking a qdev property very much > > > because it doesn't make sense to me*. But I remember Kevin had his > > > reasons (even though I can no longer remember them) for asking for it, > > > and I don't have any besides "It doesn't make sense to me". After having > > > though a bit about it (= having written three paragraphs and deleted > > > them again), I guess I can make some sense of it, though it seems to be > > > a rather esoteric use case still; it appears to me that a guest could > > > use it to signal that it's fine with some block device being shared; > > > then we could use a shared lock or none at all or I don't know. > > > Otherwise, we should get an exclusive lock for write access and a shared > > > lock for read access. > > > > The reason is pretty simple if you think about this question: Why do we > > need user input in the first place? > > I think the reason why we have an option at all is rather because of the > special > case of libguestfs [1], otherwise locks should just be acquired sensibly as > the > "auto" mode does.
It's not just that. Qemu doesn't have enough information to make the correct decision about locking automatically -- for example, Qemu doesn't know if the guest is using cluster filesystems or not (or for some other reason the guest wants a shared writable block device, eg. for running Disk Paxos). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
