From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IPljS-0007x0-RN for qemu-devel@nongnu.org; Mon, 27 Aug 2007 17:02:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IPljQ-0007vW-8w for qemu-devel@nongnu.org; Mon, 27 Aug 2007 17:02:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IPljQ-0007vJ-4h for qemu-devel@nongnu.org; Mon, 27 Aug 2007 17:02:44 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IPljP-00017W-I9 for qemu-devel@nongnu.org; Mon, 27 Aug 2007 17:02:43 -0400 Received: by wr-out-0506.google.com with SMTP id c38so2222725wra for ; Mon, 27 Aug 2007 14:02:41 -0700 (PDT) Subject: Re: [Qemu-devel] Re: [et-mgmt-tools] Image Corruption Possible with qemu and qemu-kvm From: Anthony Liguori In-Reply-To: <20070827202748.GK9043@redhat.com> References: <46D2EC13.8020005@bppiac.hu> <1188232650.25884.100.camel@localhost.localdomain> <20070827202748.GK9043@redhat.com> Content-Type: text/plain Date: Mon, 27 Aug 2007 16:02:38 -0500 Message-Id: <1188248558.21696.1.camel@squirrel> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org, Avi Kivity Cc: Fedora/Linux Management Tools On Mon, 2007-08-27 at 21:27 +0100, Daniel P. Berrange wrote: > On Mon, Aug 27, 2007 at 10:19:42PM +0200, Sven Oehme wrote: > > i thought it might be good to post this on qemu-devel as well, as i see > > this as a general qemu / kvm / xen /whatevercomesnext issue . > > > > are there any plans to implement a default in qemu to prevent accessing > > the same image multiple times ? > > Each QEMU instance is unware of each other so can't directly check this. One > possiblity would be for QEMU to use fcntl() to take a lock on a disk image > when opening it. With raw disk images at least, it is, however, safe to let > multiple QEMU instances use it at once *provided* you have a clustered > filesystem installed, rather than regular FAT or ext2/3, so one wouldn't want > to exclude this use case. > > > i know that in xen they deal with this problem somehow xen specific. > > wouldn't it be good to prevent multiple access to the same image by > > default and add a switch to overwrite it ? > > In the scenario you mention, libvirt should probably do a sanity check for > this before letting you start the guest. libvirt already supports the idea > of 'shared' disk images where two or more guests can be optionally configured > to have write access - basically assumes the admin requesting sharing knows > what they're doing. I think this is the right level myself. Advisory locks work okay but not all filesystems support them. It's particularly nasty when you have a clustered filesystem in the host. I think it would do more harm than good to have a feature like that was supposed to provide a safe-guard but then frequently didn't work. Regards, Anthony Liguori > > i corrupted a couple of virtual Linux images last week as i accidentally > > started them two times .. > > i opened a bug against qemu (not sure if this was a good idea) --> > > https://bugzilla.redhat.com/show_bug.cgi?id=253533 > > > > are there any plans to ensure that this can't happen in future releases of > > virt-manager with lock files in the image directory or similar ? > > Dan.