Avi Kivity wrote:
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a
physical device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of a read-write lock.
That is, as long as the guests are opening the file read only, you
should allow many readers. However, you should prevent anyone from
opening with write permission. Likewise, writes should prevent
future reads.
Well shared/exclusive or read/write locks support exactly that.
For non-raw storage we should take the locks unconditionally, since
there is no useful way to share such images opened for write access.
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.
Exposing exclusive/shared is probably the wrong interface. I think the
better thing to do would be to expose a boolean and then automatically
choose the proper lock type. This make require some deeper surgery to
get right as we currently don't handle cdrom's intelligently (we try to
open with write permission first).
Regards,
Anthony Liguori