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

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

[Michael Tokarev]

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

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

[Michael Tokarev]

Ping? ;)  What's the current state and/or a roadmap?
Thanks!

17.03.2010 22:49, 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?
>
> Thank you!
>
> /mjt

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

[Anthony Liguori]

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
>
>
>    

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

[Richard W.M. Jones]

On Thu, Apr 22, 2010 at 01:36:30PM -0500, Anthony Liguori wrote:
> 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.

>From the libguestfs point of view, any sort of locking would be
preferable to the current situation.  If someone wants to run with the
patch, I posted several versions and there was a lot of discussion on
qemu-devel in Nov/Dec 2009, starting with this message:

  Subject: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
  Message-ID: <20091204165301.GA4167@amd.home.annexia.org>

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

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

[Michael Tokarev]

22.04.2010 23:21, Richard W.M. Jones wrote:
> On Thu, Apr 22, 2010 at 01:36:30PM -0500, Anthony Liguori wrote:
>> 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.

For that, there's a good reply by Daniel P. Berrange, there:
http://marc.info/?l=qemu-devel&m=126018305619696&w=2

>  From the libguestfs point of view, any sort of locking would be
> preferable to the current situation.  If someone wants to run with the
> patch, I posted several versions and there was a lot of discussion on
> qemu-devel in Nov/Dec 2009, starting with this message:
>
>    Subject: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
>    Message-ID:<20091204165301.GA4167@amd.home.annexia.org>

Aha, this is the discussion I were trying to find, but failed for
some unknown reason.  Thank you Richard, I'm rehashing it all now...

/mjt