Avi Kivity wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu -drive file=cow1.img,lock=exclusive
qemu -drive file=cow2.img,lock=exclusive
With the current patch, the second command will fail and it's
impossible to invoke correctly. That's because flags are passed down
to backing devices directly. You really need to be much smarter here
in how you handle locking.
Oh, that's just an implementation bug. Obviously there's no need to
open a file for exclusive access if it will only be accessed for read
(when merging a snapshot we'd need to upgrade the lock to exclusive
while that takes place). I thought you objected to the whole concept.
I'm not sure whether it's best to enable it by default because, as I
said earlier, I'm not comfortable with the lack of correctness wrt
advisory vs. mandatory locking. Only qemu can implement this level of
locking though so it's definitely something we ought to support.
However, from a UI and implementation perspective, I think we need
significantly different semantics. You either want locking or you
don't. I don't think the selection of none|shared|exclusive really
makes sense.
Regards,
Anthony Liguori
