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

[Markus Armbruster]

Kashyap Chamarthy <address@hidden> writes:

> Hi Markus / Kevin,
>
> I've been reading some of the (long) history of 'blockdev-add', its
> goals, current status, etc.  While writing the below, I've used some
> public references[*] and tried to read related Git history along with
> some trial & error.  I'm sure I haven't even barely scratched the
> surface, given it's complexity.  So, from my minimal research, I could

Doesn't look so minimal to me...

> come up with these possible uses of 'blockdev-add' (while realizing its
> interface is still in development & may change).
>
> (0) Accepts structured JSON data as input (as opposed to a string
>     supplied to "-drive" on command-line).

That's a general difference between command line options and QMP
commands.

Compare -netdev and netdev_add: they take the same data, the former in
QemuOpts syntax, the latter in JSON.

Example:
    -netdev user,id=foo,restrict
    { "execute": "netdev_add",
      "arguments": { "id": "foo", "type": "user", "restrict": true } }

QemuOpts is designed for a single, flat dictionary.  Kevin has pushed it
well beyond that, but its usability breaks down pretty rapidly once you
start to nest stuff.  JSON is designed for trees, and has an actual type
system.

> (1) Hot-plug (or unplug via 'x-blockdev-del') of block devices (while,
>     obviously, you can't run the command-line "-drive" at run-time).
>     A trivial example (could imagine more complex examples involving
>     NBD, I/O throttling, etc):
>
>    QMP> { "execute": "blockdev-add",
>      "arguments": { "options" : { "driver": "qcow2", 
>                                  "id": "drive-ide2-0-0",
>                                  "file": { "driver": "file",
>                                            "filename": "/export/disk2.qcow2"} 
> } } } 

We refused to port HMP command drive_add to QMP, because it's messed up
in ways that are anathema to QMP.  Instead, we envisaged creating a
cleaner command, namely blockdev-add.  And envisaged it has effectively
remained ever since.  Except we prefer to call it "experimental".  Only
now are we getting close to completing the job.

> (2) "Override the backing file[%] with a file descriptor" [From Markus'
>     2013 talk[1]]
>       - I presume libvirt is the potential primary user here, since it
>         deals with file descriptors.
>
>       - [%] Not just the backing file, but also the ability to override
>         backing file format, and cache mode
>          - [Reference: Discussion of reconfiguration of backing file
>            cache mode by Kevin at his 2014 KVMForum talk.]

Yes.  I think this is the primary reason for doing all this work.

As our 2013 talk explains, inside a block backend there is a graph of
block driver instances.  Traditional -drive / drive_add is a hodge-podge
of special cases and little languages to let users specify some graphs.
blockdev-add sets out to let users specify arbitrary graphs, node by
node.

The examples you quoted are important cases where -drive lets you build
the graph, but doesn't provide sufficient control over certain nodes.

> (3) I've relistened to the 2014 talk "More Block device configuration",
>     a quick couple of points below [I first quote the text, from Kevin,
>     and then ask my clarification / question]:
>
>     When using 'blockdev-add' (to open block devices):
>
>      - "All required options are specified.  Optional options get
>        defaults"
>
>          - Such as?

Details...  I've been away from the blockdev-add work for long enough to
have forgotten them %-}

Kevin?

>      - "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?

>  (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?

>  (5) ?
>
> Thanks for reading.
>
> - - -
>
> [*] I've used these as references:
>
> [1] Markus / Kevin's 2013 "Block device configuration done right"
> [2] Kevin / Max's KVMForum 2014 talk on "More Block device configuration"