[Qemu-devel] Review of ways to create BDSes (was: Review of monitor commands identifying BDS / BB by name)

[Markus Armbruster]

= Introduction =

BDSes can be opened in various ways.  Some of them don't provide for
user configuration.  Some of them should.

Example: -drive format=qcow2,file=foo.qcow2 where foo.qcow2 has a raw
backing file foo.raw.  This creates the the following tree of BDSes:

            (qcow2,foo.qcow2)
              /            \
    (file,foo.qcow2)    (raw,foo.raw)
                            |
                       (file,foo.raw)

Before Kevin added driver-specific options, -drive let you configure
basically just the root.  Configuration for the others was inferred from
the root's configuration and the images.  Driver-specific options let
you configure all the nodes.  Defaults are still inferred as before.

Example: blockdev-snapshot-sync provides only a small subset of the full
configuration options for the BDS it creates.  Could be fixed by
duplicating the full options, i.e. blockdev-add's.  But a command that
just snapshots and leaves BDS creation to blockdev-add would be cleaner.

This is a systematic review of all the ways you can open BDSes in qemu
proper, i.e. not in qemu-{img,io,nbd}.  I tracked them down by following
the call chains leading to bdrv_open().


= QMP Commands =

* block-commit

  I figure this clones the @base BDS initially, and replaces it by the
  clone finally.  Is support for user configuration for this clone
  wanted?

* blockdev-add

  Boils down to a bdrv_open(), which is discussed in the next section.

* blockdev-snapshot-sync

  Creates a new image and a new BDS with only a few configuration
  options: @snapshot-file (the filename), @snapshot-node-name,
  @format=qcow2, @mode.  Conflates three operations: create image, open
  image, snapshot.  I guess we want to replace it by a basic snapshot
  operation that can be used with with blockdev-add and some command to
  create images.

* change

  Closes, then opens a BDS with just two configuration options: @target
  (the filename) and @arg (the format).  Needs replacing.

* drive-backup

  Similar to blockdev-snapshot-sync, except the filename is called
  @target, and the node name can't be configured.  I guess we want to
  replace it by a basic backup operation.

* drive-mirror

  Similar to blockdev-snapshot-sync, except the filename is called
  @target, and the node name @node-name.  I guess we want to replace it
  by a basic mirror operation.

* transaction

  This is a wrapper around a list of transaction-capable commands.
  Thus, nothing new here.


= Generic block layer =

bdrv_open() opens a BDS and possibly children "file" and "backing"
according to its configuration.

Subtypes of BlockdevOptionsGenericFormat have configuration for "file".

Subtypes of BlockdevOptionsGenericCOWFormat additionally have
configuration for "backing" (defaults to "infer from COW image").

bdrv_open() can additionally splice in a QCOW2 BDS to implement
snapshot=on.  No way to configure, but that's okay, because it's a
convenience feature, and to configure you simply do the splicing
explicitly.


= Block driver methods =

== bdrv_create() ==

The BDSes created here are all internal temporaries of the method, hence
user configuration isn't needed.  Correct?

== bdrv_file_open() ==

* quorum_open()

  Creates / connects to its children according to configuration in
  BlockdevOptionsQuorum.

* blkdebug_open()

  Creates / connects to its children according to configuration in
  BlockdevOptionsBlkdebug.

* blkverify_open()

  Creates / connects to its children according to configuration in
  BlockdevOptionsBlkverify.

* vvfat's enable_write_target()

  You don't want to know.

== bdrv_open() ==

* vmdk_open()

  Creates BDSes for its extents, configuration inferred from images.
  Looks like this needs work.


= Xen =

blk_connect() calls bdrv_open() under a /* setup via xenbus */ heading.
Looks like backward compatibility crap to me.