Re: [Qemu-block] Potential uses of 'blockdev-add'

[Max Reitz]

On 09.08.2016 18:21, Markus Armbruster wrote:
> Kashyap Chamarthy <address@hidden> writes:

[...]

>>      - "But '-drive' makes things a bit more complicated than
>>        'blockdev-add' because things that are required for
>>        'blockdev-add' are actually optional in '-drive'; and figuring them
>>        out, at times, is not quite easy.  For example, not even the
>>        block driver name is required in '-drive' because we have things
>>        like probing of the image format." 
>>
>>         - So, it seems like the above is still the case.  As a quick
>>           example, I took the QMP example from point (1) above, and
>>           tried it on command-line, with '-drive' both the below options
>>           are valid (QEMU boots just fine with):
>>
>>           (a) explicitly specify the format driver ("driver=qcow2"):
>>
>>               -drive 
>> driver=qcow2,id=drive-ide2-0-0,file.driver=file,file.filename=./disk2.qcow2
>>
>>           (b) omit the format driver:
>>
>>               -drive 
>> id=drive-ide2-0-0,file.driver=file,file.filename=./disk2.qcow2
>>
>>           I assume the above is what Kevin means.
> 
> Kevin?

Yes, it is, and you can omit file.driver, too.

>>  (4) "If at all possible, we'd like to use 'blockdev-add' for all
>>      images QEMU opens" [from 'Make everything use blockdev-add'
>>      section from Kevin / Max's talk[2]]
>>
>>       - Can someone elaboarate a bit more on this?
> 
> Kevin, Max?

Well, there are two things this can mean. One is that -drive should
exercise the same code path at blockdev-add, and actually it pretty much
does, at least insofar that -drive's functionality is a superset of that
of blockdev-add, so it can only use blockdev-add's code for that part of
its functionality. In the future, we might want to go further than this
and actually translate -drive into a set of QMP commands, but we don't
have the full -drive functionality in QMP yet (without resorting to
HMP's drive_add, that is).

Also, there's the some-parameters-are-optional issue you talked about
above. How do you translate -drive if=none,file=foo.img to a
blockdev-add command? It gets tricky because you have to specify some
format, but you actually cannot because you don't know it. That is one
reason we may introduce a probing block driver at some point or another
(i.e. you specify "probe-format" or something as the driver and this
will then cause qemu to probe the format).

The other thing I can imagine is the idea that management tools should
(at least be able to) start a bare-bone qemu which actually doesn't have
anything on it (no hardware other than a motherboard) and then begin to
plug stuff into it at runtime instead of on the command line.

One reason one might want to do this is "because you can". Another is
that the process of making qemu able to start without anything would
probably make it possible to reduce start-up times for light-weight VMs
by a lot.

Apart from that, one could probably consider -drive legacy and
blockdev-add not-so-legacy, because the latter is effectively more
powerful (-drive and blockdev-add pretty much give you the same
features, but using the command line to construct a large BDS tree is
pretty icky, so you probably don't want to use -drive for large BDS
trees) and simpler to use by management tools.

Finally, if we ever get to the point where we can and do translate
-drive to a set of QMP commands, there really is no difference between
whether it's qemu or the management layer which does this translation.

Max

signature.asc
Description: OpenPGP digital signature