From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOqm7-0001c0-K2 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 05:18:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOqm6-0001Ze-3L for qemu-devel@nongnu.org; Fri, 01 Aug 2008 05:18:14 -0400 Received: from [199.232.76.173] (port=44266 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOqm5-0001ZA-UW for qemu-devel@nongnu.org; Fri, 01 Aug 2008 05:18:14 -0400 Received: from mx1.redhat.com ([66.187.233.31]:53061) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOqm5-0001a5-JQ for qemu-devel@nongnu.org; Fri, 01 Aug 2008 05:18:13 -0400 Date: Fri, 1 Aug 2008 10:18:09 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file Message-ID: <20080801091809.GJ23993@redhat.com> References: <20080731113120.GJ23888@redhat.com> <489203C9.1040607@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489203C9.1040607@codemonkey.ws> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Thu, Jul 31, 2008 at 01:26:17PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >The current block driver code will attempt to open a file backing a drive > >for read/write with O_RDWR first, and if that fails, fallback to opening > >it readonly with O_RDONLY. So if you set file permissions to readonly on > >the underlying drive backing store, QEMU will fallback to opening it read > >only, and discard any writes. > > > > I'm not sure I agree that this patch is really that useful to an actual > user. I think we'll eventually need a read-only flag as paravirtual > devices do support read-only block devices. Let's consider a scenario: > > A user has multiple block devices including a secondary device that is > read-only to the guest. With qcow2 and today's behavior, savevm will > just work. With your patch, it will not work. > > This is a scenario where just because the block device cannot be written > to, we still would want to write to the metadata of the image. Sure, the admin of the guest has the option to make it read only or not depending on whether they need to use this capability. > 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 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|