On Wed, Aug 10, 2016 at 12:03:10AM +0200, Max Reitz wrote: > On 09.08.2016 18:21, Markus Armbruster wrote: > > Kashyap Chamarthy <[email protected]> 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
