On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <arm...@redhat.com> wrote:
> Stefan Hajnoczi <stefa...@gmail.com> writes:
>
>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <arm...@redhat.com> 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
