qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs


From: Markus Armbruster
Subject: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
Date: Mon, 31 May 2010 12:54:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Avi Kivity <address@hidden> writes:

> On 05/28/2010 09:21 PM, Markus Armbruster wrote:
>
> <snip, agreed>
>
>> Summary of the host / guest split:
>>
>> -drive options                      host or guest?
>> bus, unit, if, index, addr          guest, already covered by qdev
>> cyls, heads, secs, trans            guest, new qdev properties
>>                                        (but defaults depend on image)
>> media                               guest
>> snapshot, file, cache, aio, format  host, blockdev_add options
>>    
>
> We expose some of the cache property to the guest.  IMO we need the
> cache property to be both guest and host, with qemu bridging the
> impedance mismatch if needed.

Yes.

How should the device properties look like?

>> rerror, werror                      host, guest drivers will reject
>>                                        values they don't support
>>    
>
> Did you mean 'block format drivers will reject'?

No.  Actual implementation is in the guest drivers,
e.g. ide_handle_rw_error().

I see this as the host outsourcing the actual work to guest drivers.
Guest drivers that can't do the work should complain.  Right now, they
silently ignore the order.

>> serial                              guest, new qdev properties
>> readonly                            both host&  guest, qdev will refuse
>>                                        to connect readonly host to read/
>>                                        write guest
>>
>> QMP command docs:
>>
>> blockdev_add
>> ------------
>>
>> Add host block device.
>>
>> Arguments:
>>
>> - "id": the host block device's ID, must be unique (json-string)
>>    
>
> Unique in which namespace?  A global ID namespace if fine.

The device ID namespace.

We have numerous ID namespaces already: each QemuOptsList, device IDs
(which happens to be a superset of QemuOptsList qemu_device_opts),
perhaps more.

>> - "file": the disk image file to use (json-string, optional)
>> - "format": disk format (json-string, optional)
>>      - Possible values: "raw", "qcow2", ...
>>    
>
> Need some way to list supported formats.

See below.

>> - "aio": host AIO (json-string, optional)
>>      - Possible values: "threads" (default), "native"
>>    
>
> Need some way to list supported options.
>
>> - "cache": host cache usage (json-string, optional)
>>      - Possible values: "writethrough" (default), "writeback", "unsafe",
>>                         "none"
>>    
>
> ...
>
>> - "readonly": open image read-only (json-bool, optional, default false)
>> - "rerror": what to do on read error (json-string, optional)
>>      - Possible values: "report" (default), "ignore", "stop"
>>    
>
> ...
>
>> - "werror": what to do on write error (json-string, optional)
>>      - Possible values: "enospc" (default), "report", "ignore", "stop"
>>    
>
> ...
>> - "snapshot": enable snapshot (json-bool, optional, default false)
>>
>>    
>
> An alternative to the "Need some way to list *" is to provide another
> query capability, akin to KVM_CAP_..., but I think listing is
> superior.
>
>> Example:
>>
>> ->  { "execute": "blockdev_add",
>>               "arguments": { "format": "raw", "id": "blk1",
>>                              "file": "fedora.img" } }
>> <- { "return": {} }
>>
>> Notes:
>>
>> (1) If argument "file" is missing, all other optional arguments must be
>>      missing as well.  This defines a block device with no media
>>      inserted.
>>
>> (2) It's possible to list supported disk formats by running QEMU with
>>      arguments "-blockdev_add \?".
>>    
>
> Ok, so there's a partial answer here.

For human users, we need accurate interactive help, both for fixed sets
of options like "cache", and for configurable sets like "format".
-blockdev_add \? simply follows existing usage there.

We need to make QMP "self-documenting": describe commands, arguments,
argument values and so forth with sufficient completeness.  In
particular, for arguments that are enumerations, enumerate all possible
values.

>> blockdev_change
>> ---------------
>>
>> Change host block device media.
>>
>> Arguments are exactly like blockdev_add.
>>
>> Notes:
>>
>> (1) If argument "file" is missing, all other optional arguments must be
>>      missing as well.  This ejects the media without inserting a new one.
>>    
>
> Maybe we want an explicit blockdev_eject instead, not sure.

Either blockdev_change (can eject, insert with auto-eject) or completely
orthogonal blockdev_eject (can only eject) + blockdev_insert (can only
insert, no auto-eject), I'd say.

Thanks for the review!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]