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

[Stefan Hajnoczi]

On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <address@hidden> wrote:
> Stefan Hajnoczi <address@hidden> writes:
>
>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <address@hidden> wrote:
>>> blockdev_add
>>> ------------
>>>
>>> Add host block device.
>>>
>>> Arguments:
>>>
>>> - "id": the host block device's ID, must be unique (json-string)
>>> - "format": image format (json-string, optional)
>>>    - Possible values: "raw", "qcow2", ...
>>
>> What is the default when unset?  (I expect we'll auto-detect the
>> format but this should be documented.)
>
> For command line and human monitor, we definitely want a sensible
> default.  I sketched one in section "Command line syntax".  I'll quote
> it for your convenience a few lines down.

Ahem...the part that I skipped over ;).  I should have read your
entire email, thanks for pointing it out.

> To let users ask for this explicitely, we could have pseudo-format
> "auto".
>
> We also need a pseudo-format "probe", which guesses the format from the
> image contents.  Can't be made the default, because it's insecure.

In which scenario is probing the image format a security issue?  I'm
trying to think up scenarios where a cloud user modifies the guest
disk image and gets QEMU to re-open the image file as another format,
perhaps this would make the cloud owner/admin unhappy.  I don't see a
threat except for image format drivers have security bugs (corrupt
images leading to arbitrary code execution).

>>> (2) It's possible to list supported disk formats and protocols by
>>>    running QEMU with arguments "-blockdev_add \?".
>>
>> Is there an query-block-driver command or something in QMP to
>> enumerate supported formats and protocols?  Not sure how useful this
>> would be to the management stack - blockdev_add will probably return
>> an error if an attempt is made to open an unsupported file.
>
> QMP should be "self-documenting": a client should be able to list
> commands, their arguments, and possible argument values.  Listing
> supported formats then becomes "list possible values of command
> blockdev_add's argument format".

Nice :).

>>> blockdev_del
>>> ------------
>>>
>>> Remove a host block device.
>>>
>>> Arguments:
>>>
>>> - "id": the host block device's ID (json-string)
>>>
>>> Example:
>>>
>>> -> { "execute": "blockdev_del", "arguments": { "id": "blk1" } }
>>> <- { "return": {} }
>>
>> What about an attached guest device?  Will this fail if the virtio-blk
>> PCI device is still present?  For SCSI I imagine we can usually just
>> remove the host block device.  For IDE there isn't hotplug support
>> AFAIK, what happens?
>
> Command fails.  You have to device_del the device first.  Which is only
> possible if its bus supports hot-plug.

I think this deserves to be in the documentation.

Stefan