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? Thank you! /mjt
