From: Jamie Lokier <jamie@shareable.org>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Naphtali Sprei <nsprei@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Add readonly flag to -drive command
Date: Mon, 12 Oct 2009 14:50:32 +0100 [thread overview]
Message-ID: <20091012135032.GA13560@shareable.org> (raw)
In-Reply-To: <4AD32DF6.4050100@redhat.com>
Kevin Wolf wrote:
> Am 12.10.2009 14:47, schrieb Naphtali Sprei:
> > In order to safely share an image between guests (as read only drive), add a 'readonly' flag
> > to the -drive command (qemu command line and monitor).
Heh. I've been sharing images between guests for ages - using "chmod -r" :-)
> > Still missing passing the read only attribute to the guest, where possible. I don't know which device types supports
> > read only, and don't know how to pass this information to guests.
This was discussed in a thread some months ago. You might look it up.
SCSI, USB, and floppy can pass the information to guests - see the
Linux kernel for how the flag is read. CD-ROMs are read-only already
of course. I don't know if virtio-blk can; if not, it would be good to
add it. Not sure about the latest iterations of PATA/SATA.
Read-only images are particularly useful for the backing file for a
qcow2 image or -snapshot. Then the guest doesn't need to know
anything, but 'savevm', 'delvm' and 'commit' need to be stopped from
trying to modify the backing file. (But it's fine for -snapshot +
commit to modify a writable qcow2 file which _itself_ has a read-only
backing file, as long as 'commit' doesn't try to push the commit
further back than one level).
> > Also not sure what to do when qemu cannot open the file as
> > writeable. Currently it opens it as read only. We might change it
> > to give a warning or even an error.
I think that's a good plan, but please don't break the current
situation, where it's possible to "chmod -r" an image file and then
share it safely, until the 'readonly' flag is a usable replacement.
> Is this enough? Basically none of the block drivers know that their
> image could be read-only, so we'll likely trigger some unexpected error
> cases there. For a simple write I guess we'll be okay (not sure if we'll
> return the right error code, though), but I have no idea what, say,
> savevm would do with a read-only image.
Right now there is already a 'readonly' flag called 'chmod -r image',
because QEMU opens a file read-only if it can't open it writable, so
it's not a new case. Just moving it from the filesystem into QEMU.
When opened read-only, it would be better for the block drivers to
return an error themselves, instead of trying to write and (hopefully)
getting a host OS error.
I doubt if read-only errors have been tested or accomodated, or if
they are reported well to guests as the right sort of error. I'm
pretty sure the read-only _flag_ isn't passed through guest interfaces
for the guest OS to use yet, but that should be quite easy.
-- Jamie
next prev parent reply other threads:[~2009-10-12 13:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 12:47 [Qemu-devel] [PATCH] Add readonly flag to -drive command Naphtali Sprei
2009-10-12 13:24 ` Kevin Wolf
2009-10-12 13:50 ` Jamie Lokier [this message]
2009-10-12 14:07 ` Kevin Wolf
2009-10-12 14:30 ` Anthony Liguori
2009-10-12 15:16 ` Jamie Lokier
2009-10-12 16:15 ` Michael Tokarev
2009-10-13 7:36 ` Kevin Wolf
2009-10-12 14:06 ` Anthony Liguori
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=20091012135032.GA13560@shareable.org \
--to=jamie@shareable.org \
--cc=kwolf@redhat.com \
--cc=nsprei@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.