Re: [Qemu-devel] Review of monitor commands identifying BDS / BB by name

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3855 bytes --]

On 12/04/2014 08:56 AM, Markus Armbruster wrote:

> 
> @device is a sub-optimal name for this single parameter.  Either we
> accept that and move on, or we deprecate it in favor of a new parameter
> with a better name.  I guess the better name isn't worth that much
> trouble, in particular since the command name is already ugly.
> 
> When @node-name is given, @device must not be given.  So @device is
> mandatory *except* in the @node-name usage we retain for compatibility.
> Deprecate the usage.
> 
> Command documentation could then look like this:
> 
> ##
> # @block-resize
> #
> # Resize a block image while a guest is running.
> #
> # @device: the name of the block backend or node to resize (node names
> # supported since 2.3)
> #
> # @size: new image size in bytes
> #
> # Deprecated usage (since 2.3):
> #
> # @device: #optional the name of the block backend to resize
> #
> # @node-name: #optional name of the node to resize (since 2.0)
> #
> # Either @device or @node-name must be set but not both.

But this isn't discoverable.  You aren't changing whether any parameters
are optional, only enhancing the semantics of existing parameters.  How
is libvirt supposed to know if qemu is old (node names have to go
through node-name) or new (node names are preferred through device)?
Just blindly try the 'device' argument, and if it fails, fall back to an
attempt with node-name?

On the other hand, if 'node-name' becomes the preferred interface, then
libvirt has a solution: if node-name is present (it is easy during
up-front QMP probing to determine whether 'node-name' is a recognized
optional argument or an unknown argument), then always use node-name.
As long as libvirt always names the nodes of each device (which it
should be doing, but that's a patch series for another day and another
list), then a device lookup is never needed.  If 'node-name' is not
present, then only the 'device' form is supported, and libvirt can only
manage the top image of a backend (but can make that point obvious to
the end user that they should upgrade qemu for more functionality).


> Let's get the easy case out of the way first: a query that reports only
> backend properties and not node properties can return an array where
> each element carries a backend name, like query-block does now.
> 
> For queries that report node properties, we have a couple of options:
> 
> * Flat array with node names
> 
>   Like current query-named-block-nodes.
> 
>   Can't report on nodes without names.  Jeff's project to give all nodes
>   names would moot this issue.

I could live with this.

> 
> * Array of trees mirroring the actual node forest,
> 
>   Similar to current query-blockstats.
> 
>   Tree roots correspond to backends, and backends have names.
> 
>   Unfortunately, the nodes don't actually form a forest: node trees may
>   be shared.  To turn it into make a forest, we'd have to duplicate the
>   shared trees.
> 
> * Hybrid: array of trees, but named sub-trees are represented by name
> 
>   Like the previous one, except the recursion stops at named nodes.
>   Instead of including such a sub-tree, we reference it by name, then
>   add it to the array if it's not already there.

This one seems like it might be easier for avoiding the reconstruction
of relationships; but if management doesn't already know relationships,
I'm not sure it is worth the complexity.

> 
> "Flat array" seems simplest.

Simplest to implement.  Management can't easily reconstruct the tree,
but for looking up information about a known node, iterating over the
simpler structure will be faster than trying to find a known node in a
complex structure.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]