From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGckT-0000St-1Q for qemu-devel@nongnu.org; Tue, 16 Jun 2009 13:47:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGckM-0000S6-PE for qemu-devel@nongnu.org; Tue, 16 Jun 2009 13:47:03 -0400 Received: from [199.232.76.173] (port=36554 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGckM-0000S3-Ky for qemu-devel@nongnu.org; Tue, 16 Jun 2009 13:46:58 -0400 Received: from mail2.shareable.org ([80.68.89.115]:57572) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGckM-0000q2-7g for qemu-devel@nongnu.org; Tue, 16 Jun 2009 13:46:58 -0400 Date: Tue, 16 Jun 2009 18:46:53 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Regression opening read-only cdroms Message-ID: <20090616174653.GA11893@shareable.org> References: <4A37896C.8050208@redhat.com> <20090616143259.GA29040@shareable.org> <4A37B23F.6040604@eu.citrix.com> <20090616145421.GD29040@shareable.org> <4A37C82B.5030805@codemonkey.ws> <4A37D30D.40003@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A37D30D.40003@eu.citrix.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Christoph Hellwig , qemu-devel , Avi Kivity Stefano Stabellini wrote: > Anthony Liguori wrote: > > > Jamie Lokier wrote: > >>> Indeed. > >>> I have a patch that adds bdrv_set_read_only that set bs->read_only = 1 > >>> so that bdrv_open2 can check if the flag is set and act accordingly. > >>> The problem is that in xen we read whether the device should be opened > >>> read only in the VM config file, I don't think the user can specify to > >>> open a drive read-only in qemu. > >>> > >> What's missing is a "ro" sub-option to "-drive". > >> > > > > It only is useful if we can expose that read-only attribute to the > > guest. You can't do that consistently with all block devices so the > > result would be that you'll fail write operations causing a guest to crash. You should get disk write errors, rather than a simple crash. Any decent operating system will spew a lot of printks, which is a clue. > > This is not friendly to a user who expects that ro would Just Work. I don't agree that it's not friendly, because I think it's quite obvious what behaviour to expect. Users who don't know what a read-only disk would do can use virt-manager and that can warn them when they try to tick the option, or equally likely hide the option so they can never find it :-) We already have a user interface for it: chmod. That's less friendly, but it's the same result. Users who expect things to just work will be even more surprised that "-hda image" where image is read-only does not give any error from QEMU, but their guest crashes. Or that "-hda image" works as usual, and their guest crashes, and eventually they discover it's because their disk image is not writable, and it's always worked before because they were using -snapshot or something like that, and QEMU didn't warn them it would be a problem... > Well, it could Just Work for cdrom. It would Just Work for several media types (cdrom, floppy), and for hard disks on certain interfaces (virtio, SCSI, USB). Yes, virtio, SCSI and USB have read-only storage flags. It is also appropriate for disks that you intent to always mount read-only in the guest anyway, even if the interface doesn't have a flag, just to protect the image from aberrant guest behaviour. -- Jamie