From: Avi Kivity <avi@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Christoph Hellwig <hch@lst.de>,
qemu-devel <qemu-devel@nongnu.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] Regression opening read-only cdroms
Date: Tue, 16 Jun 2009 20:54:44 +0300 [thread overview]
Message-ID: <4A37DC64.4090501@redhat.com> (raw)
In-Reply-To: <20090616174653.GA11893@shareable.org>
On 06/16/2009 08:46 PM, Jamie Lokier wrote:
>>> 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.
>
I don't consider this useful behaviour and see no motivation to support it.
> 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...
>
I agree, for non-cdroms/floppies, non-backing store files we should
require write access.
> 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.
>
Maybe -drive ...,snapshot. The disk will be writable, just not persistent.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2009-06-16 17:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 12:00 [Qemu-devel] Regression opening read-only cdroms Avi Kivity
2009-06-16 14:33 ` Jamie Lokier
2009-06-16 14:54 ` Stefano Stabellini
2009-06-16 14:54 ` Jamie Lokier
2009-06-16 16:28 ` Anthony Liguori
2009-06-16 17:14 ` Stefano Stabellini
2009-06-16 17:46 ` Jamie Lokier
2009-06-16 17:54 ` Avi Kivity [this message]
2009-06-16 18:56 ` Jamie Lokier
2009-06-16 19:02 ` Jamie Lokier
2009-06-16 21:11 ` Gerd Hoffmann
2009-06-17 6:27 ` Avi Kivity
2009-06-16 15:16 ` Avi Kivity
2009-06-16 15:54 ` Jamie Lokier
2009-06-16 16:17 ` Avi Kivity
2009-06-16 17:51 ` Jamie Lokier
2009-06-16 17:58 ` Avi Kivity
2009-06-18 12:37 ` Richard W.M. Jones
2009-06-24 20:23 ` Jamie Lokier
2009-06-24 22:43 ` Richard W.M. Jones
2009-06-25 0:50 ` Jamie Lokier
2009-06-25 8:17 ` Richard W.M. Jones
2009-06-16 16:28 ` Blue Swirl
2009-06-16 18:37 ` Blue Swirl
2009-06-16 21:16 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A37DC64.4090501@redhat.com \
--to=avi@redhat.com \
--cc=hch@lst.de \
--cc=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).