From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4tLR-0007Hg-7h for qemu-devel@nongnu.org; Thu, 22 Apr 2010 06:09:17 -0400 Received: from [140.186.70.92] (port=48615 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4tLO-0007G4-TP for qemu-devel@nongnu.org; Thu, 22 Apr 2010 06:09:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4tLJ-000377-KT for qemu-devel@nongnu.org; Thu, 22 Apr 2010 06:09:14 -0400 Received: from isrv.corpit.ru ([81.13.33.159]:53279) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4tLJ-00035k-9J for qemu-devel@nongnu.org; Thu, 22 Apr 2010 06:09:09 -0400 Message-ID: <4BD02040.3060808@msgid.tls.msk.ru> Date: Thu, 22 Apr 2010 14:09:04 +0400 From: Michael Tokarev MIME-Version: 1.0 Subject: Re: [Qemu-devel] Locking block devices for concurrent access? References: <4BA1323F.6080501@msgid.tls.msk.ru> In-Reply-To: <4BA1323F.6080501@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel 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