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

[Kashyap Chamarthy]

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

(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"} } 
} } 

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

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

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

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

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


-- 
/kashyap