Re: [Qemu-devel] Locking block devices for concurrent access?

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/17/2010 02:49 PM, Michael Tokarev wrote:
> I remember quite long discussion about this issue
> a while back.  But unfortunately, a) I can't find
> it now, and b) as far as I remember, there was no
> definitive solution presented at that time.  So I
> thought it's Ok to ask again to get more conclusive
> answer...
>
> The original problem is that currently qemu provides
> no attempt to prevent concurrent access to the same
> "virtual disk" by multiple qemu instances, or it can
> happily pass a filesystem mounted in host to a guest
> it runs.
>
> I understand pretty well that there are valid usage
> cases for multiple qemu guests having the same block
> device (file, whatever) open at the same time, even
> in read-write mode (but it is still not quite safe
> for formats with a structure, like qcow for example).
> There are cluster filesystems out there, which works
> on shared storage devices.
>
> But the thing is that in almost all "usual" cases,
> non-cluster filesystem will be used in guests, and
> it'd be _very_ useful for qemu to actually at least
> try to warn user that the given device is already
> in use.  Because it is quite easy to trash the guest
> filesystem by "mounting" the same "device" in two
> different guests at the same time (or in host and in
> guest simultaneously, for that matter).  I've run
> across this already myself, not once, and there are
> other people who've hit the same trap.
>
> I understand also that there are qcow[2] base images
> which needs to be opened in different locking mode,
> since they're usually read-only; and even there, it'd
> be a good idea to ensure that the base image is not
> open in RW mode already, or that it WILL not be opened
> RW while we're basing on it.  Or something like that
> anyway.
>
> The mentioned discussion which I can't find - there
> was a proposal to add an argument like "share-mode"
> or "lock" to -drive foo=bar,xyz=asdf parameter list,
> with values from the set "none", "shared", "exclusive".
> But what I can't remember is what the conclusion was...
>
> Can we please have some summary of where it all sits
> nowadays?
>    

I think we got to the point where there was general agreement on the 
usefulness of lock=read|write but where there was still some contention 
was on this whole notion of lock=exclusive|shared.

I believe Richard Jones was driving the original patch and his use case 
was libguestfs which really wants lock=exclusive (sort of).  But IMHO, 
it's very confusing compared to lock=read|write.

If someone did a lock=read|write patch, I think it would be applied 
without much fuss.  I think for lock=exclusive|shared, we would need a 
bit more thinking about the use-cases.

Regards,

Anthony Liguori

> Thank you!
>
> /mjt
>
>
>