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

[Kashyap Chamarthy]

On Wed, Aug 10, 2016 at 12:03:10AM +0200, Max Reitz wrote:
> 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.

Thanks Max, and Markus for the detailed context & clear explanations.
This clarifies my questions so far.


-- 
/kashyap