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?