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

[Kevin Wolf]

Am 10.08.2016 um 00:03 hat Max Reitz geschrieben:
> 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

You wish! :-)

-drive cannot create BlockDriverStates without a BlockBackend. Which is
the reason why I started to think we will get a -blockdev after all.

> 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).

I don't think translating it into QMP will be easy enough for -drive to
make it worthwhile. Things may look a bit different with a new
-blockdev.

> 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.

And the real reason is to get rid of duplication: Only one interface to
configure block devices instead of two separate ones (QMP and command
line) which have to be supported both in qemu and in management tools.

> 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.

Kevin

pgp66oLDJ0TiI.pgp
Description: PGP signature