From: Michael Tokarev <mjt@tls.msk.ru>
To: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Locking block devices for concurrent access?
Date: Wed, 17 Mar 2010 22:49:19 +0300 [thread overview]
Message-ID: <4BA1323F.6080501@msgid.tls.msk.ru> (raw)
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
next reply other threads:[~2010-03-17 19:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 19:49 Michael Tokarev [this message]
2010-04-22 10:09 ` [Qemu-devel] Locking block devices for concurrent access? Michael Tokarev
2010-04-22 18:36 ` Anthony Liguori
2010-04-22 19:21 ` Richard W.M. Jones
2010-04-22 19:57 ` Michael Tokarev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA1323F.6080501@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).