Re: [Qemu-devel] [PATCH v6 for 2.1 01/10] block: Auto-generate node_names for each BDS entry

[Eric Blake]

On 06/19/2014 06:30 AM, Jeff Cody wrote:

>>> If node_names are automatically generated when not specified, that means
>>> that all block job operations can be done by reference to the unique
>>> node_name field.  This eliminates ambiguity in resolving filenames
>>> (relative filenames, or file descriptors, symlinks, mounts, etc..) that
>>> qemu currently needs to deal with.
>>>

>> Who is this feature for?
>>
>> Human users: they'll need to  read through query-named-block-nodes
>> output to find the nodes they care about.  This is pretty cumbersome and
>> not human-friendly.
>>
> 
> Currently, that is how a human user would find the node-names.  That
> doesn't mean there might not be a new interface later on, that is more
> human friendly.
> 
> And while a human parsing query-named-block-nodes isn't fun, I think
> it is easier than a human assigning node-names to a graph, so it is
> more human-friendly than the current system.

I tend to agree here - it's easier to have a node name always present
(even if I have to look it up, and even if the lookup is a bit painful)
than it is to do experiments with block commands, and then realize only
after the fact that I forgot to name a node.  As a developer working on
a new algorithm in a management app for a particular sequence of chain
operations, I'd then know to fix up my code to add in explicit
node-naming earlier in the sequence anywhere that I had to use a
generated name later in the sequence, thanks to this visibility of a
node name through the human interfaces that I'm experimenting with.

> 
>> Management tools: parsing query-named-block-nodes isn't trivial since
>> the output can vary between QEMU versions (e.g. when we move I/O
>> throttling to a block driver node there will be new internal nodes).
>> Tools doing this should really use blockdev-add instead and assign their
>> own node names.
> 
> Libvirt (and OpenStack) is already testing with these patches, and my
> impression from Eric is that parsing the output of
> query-named-block-nodes was less work than assigning node-names in
> libvirt.

Actually (and some of this came from IRC) - libvirt isn't QUITE using
node-name yet.  As long as a backing chain is ALL local files, or ALL
gluster, then libvirt's current approach of using file names (whether
relative or absolute) has so far been sufficient to get everything done
we need for the current features being added to libvirt.  But yes,
definitely down the road, we plan on using node names.  Why? Because it
is impossible to have a mixed-mode chain (some local, some gluster) and
still have a sane way to refer to all elements in that chain without
node names.  It's just that it will be a long-term project that may take
several more months and refactorings in libvirt before we get there, so
we're not in a huge rush to have it supported directly in qemu 2.1.

> 
> Can you expand a bit on moving i/o throttle to a block, and creating
> new internal nodes?
> 
> The generated node-names have the same life cycle as a specified
> node-name; anything that would invalidate a generated node-name would
> invalidate a specified node-name as well.
> 
> And if a QMP command is issued that would cause new nodes to be
> assigned, I believe libvirt is aware that they need to perform a
> query-named-block-nodes again.

Yes - my goal with libvirt is to avoid generated names in all libvirt
interactions - but to have them as a nice fallback to show where I have
not yet met that goal.

> 
>>
>> It seems like neither type of user will get much mileage out of this
>> feature.  Is it really necessary or did I miss a use case?
>>
> 
> Strictly speaking, it isn't required.  But it makes sense for QEMU to
> assign node-names to any unassigned node-names, because it does make
> life easier for both humans and management software, and QEMU is the
> only one that can always ensure that every BDS has a node-name.
> 
> It is also nice for QEMU; we can now in future versions assume that
> every BDS will always have a node-name, regardless if it has been
> assigned by the user or not.

This is another nice aspect of the feature.  Coding around optional
names is trickier than coding around something guaranteed to exist.

> 
> And the usage of the node-names is strictly optional by the human or
> management software user; neither is required to use the generated
> node-names, and are feel to specify their own node-name.  A user
> specified node-name will prevent an auto-generated one from being
> assigned for that specific BDS.
> 

I'm still in favor of this patch, even if I hope to never take advantage
of it directly from libvirt.

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

signature.asc
Description: OpenPGP digital signature