[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode |
Date: |
Fri, 01 Aug 2008 12:14:52 -0500 |
User-agent: |
Thunderbird 2.0.0.14 (X11/20080501) |
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.
- [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Daniel P. Berrange, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Anthony Liguori, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Daniel P. Berrange, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Ian Jackson, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode,
Anthony Liguori <=
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Jamie Lokier, 2008/08/01
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Ian Jackson, 2008/08/11
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Kevin Wolf, 2008/08/12
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Anthony Liguori, 2008/08/12
- Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode, Jamie Lokier, 2008/08/12