Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>
>
>