From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOyDw-0003wI-Od for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:15:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOyDv-0003ve-OY for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:15:28 -0400 Received: from [199.232.76.173] (port=34463 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOyDv-0003vZ-KW for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:15:27 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]:55435) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOyDv-0002TH-J3 for qemu-devel@nongnu.org; Fri, 01 Aug 2008 13:15:27 -0400 Received: by wr-out-0506.google.com with SMTP id c46so899022wra.18 for ; Fri, 01 Aug 2008 10:15:26 -0700 (PDT) Message-ID: <4893448C.1050508@codemonkey.ws> Date: Fri, 01 Aug 2008 12:14:52 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode References: <20080801102949.GN23993@redhat.com> <48932751.5040303@codemonkey.ws> <18579.16494.791024.25671@mariner.uk.xensource.com> In-Reply-To: <18579.16494.791024.25671@mariner.uk.xensource.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: qemu-devel@nongnu.org Ian Jackson wrote: > Anthony Liguori writes ("Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode"): > >> Allowing the user to specify what mode we use to open a file is IMHO not >> a good interface for a user. A user should only be concerned with how >> we expose a disk to the guest, not the underlying implementation of how >> we support this. It has subtle side-effects that a user is not going to >> expect unless they are intimately familiar with how QEMU is implemented >> (like snapshotting breaking). >> > > I think I agree, but with qualifications: > > The user readonly flag ought to mean > 1. qemu will definitely not permit the guest to write to the object > represented (if it is a cow file then even the cow will not be > writeable) > 2. If the emulated device type supports it the guest will be > told that it may not write to the device. If this is not possible > and the user has not overridden this check then the entire request > will be rejected (rather than exporting the device read/write). > I don't think it should be possible to override the check. If the device doesn't support it, we should reject it. However, it sounds like all the devices we emulate support some form of read-only so this is perhaps not going to be a problem. > 3. qemu will to communicate the consequences for its future use > of the underlying host operating system object(s) appropriately > to the host system (as this might be relevant for cacheing, > concurrent access, etc.) > When possible. > 4. qemu will take steps to try to ensure that bugs and missing > changes in the readonly implementation don't leave a security > hole where the I'm not at all worried about this FWIW. > > 5. Operations (such as cow commit) that would modify data > (either host data or data as seen by the guest or both) > are not supported. > I believe commit should work just as it does now. > I think 3 and 4 mean that it should pass O_RDONLY to the underlying > filesystem objects where feasible. > > I'm afraid I don't understand your point about breaking snapshotting. > Perhaps you could explain the scenario ? > qemu-system-x86_64 -drive file=foo.img -drive file=boo.img,read-only=on Down the road, you do a savevm. savevm has to create a checkpoint in all disk images. The checkpoint will be empty in boo.img but it still needs to create one. An alternative scenario would be a read-only root fs: qemu-system-x86_64 -drive file=rootfs.img,read-only=on Where you wanted to be able to do a savevm. Regards, Anthony Liguori > Ian. > > >