From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOvw2-00048v-B8 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 10:48:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOvw0-00044Q-F9 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 10:48:49 -0400 Received: from [199.232.76.173] (port=45999 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOvw0-00044A-A0 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 10:48:48 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]:43498) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOvvz-0001z7-R7 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 10:48:47 -0400 Received: by wr-out-0506.google.com with SMTP id c46so836701wra.18 for ; Fri, 01 Aug 2008 07:48:46 -0700 (PDT) Message-ID: <4893222A.6050101@codemonkey.ws> Date: Fri, 01 Aug 2008 09:48:10 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file References: <20080731113120.GJ23888@redhat.com> <489203C9.1040607@codemonkey.ws> <20080801091809.GJ23993@redhat.com> In-Reply-To: <20080801091809.GJ23993@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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" Cc: qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Thu, Jul 31, 2008 at 01:26:17PM -0500, Anthony Liguori wrote: > >> So while I think it's valid to have a "read-only disk" exposed to the >> guest, I don't think the user should have anything to do with how we >> open the file. >> >> Is there some specific circumstance you are trying to support? >> > > The scenario is that the admin wants to assign a read only disk to the > virtual machine - typically the same disk to multiple machines - and > thus want to guarentee that no one VM can write to it, since bad things > happen if you do that with non-cluster filesystems. > > Controlling this based on the underlying permissions of the file backing > the drive is not practical. Things like udev happy set permissions on > devices in /dev/ behind your back, so you'd have to edit the horrible udev > config files to make /dev/sdXX readonly. It is a far simpler task to > simply add ,mode=ro to the QEMU command line for -drive to accomplish > this, than finding the obscure file to edit to make the underling file > have read only permissions > Right, but my point is that ,mode=ro does not have to force QEMU to open the file O_RDONLY. It simply needs to prevent writes from happening. But it's important to be able to expose this property to the guest, so ,mode=ro should not be allowed for disks that do not support exposing their read-only-ness to the guest. Regards, Anthony Liguori > Daniel >