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

[Stefan Hajnoczi]

On Thu, Jun 19, 2014 at 08:30:19AM -0400, Jeff Cody wrote:
> On Thu, Jun 19, 2014 at 04:55:02PM +0800, Stefan Hajnoczi wrote:
> > On Tue, Jun 17, 2014 at 05:53:49PM -0400, Jeff Cody wrote:
> > > Currently, node_name is only filled in when done so explicitly by the
> > > user.  If no node_name is specified, then the node name field is not
> > > populated.
> > > 
> > > 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.
> > > 
> > > If a node name is specified, then it will not be automatically
> > > generated for that BDS entry.
> > > 
> > > If it is automatically generated, it will be prefaced with "__qemu##",
> > > followed by 8 characters of a unique number, followed by 8 random
> > > ASCII characters in the range of 'A-Z'.  Some sample generated node-name
> > > strings:
> > >     __qemu##00000000IAIYNXXR
> > >     __qemu##00000002METXTRBQ
> > >     __qemu##00000001FMBORDWG
> > > 
> > > The prefix is to aid in identifying it as a qemu-generated name, the
> > > numeric portion is to guarantee uniqueness in a given qemu session, and
> > > the random characters are to further avoid any accidental collisions
> > > with user-specified node-names.
> > > 
> > > Reviewed-by: Eric Blake <address@hidden>
> > > Signed-off-by: Jeff Cody <address@hidden>
> > > ---
> > >  block.c | 16 +++++++++++++++-
> > >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > 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.
> 
> > 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.
> 
> Can you expand a bit on moving i/o throttle to a block, and creating
> new internal nodes?

Currently I/O throttling is integrated into block.c.  This was done
because we had no clean way to add filter nodes (like I/O throttling,
compression, encryption, etc) on top of the format and protocol nodes.

Now we have almost reached the point where I/O throttling can be split
off into a BlockDriver.  When the feature is enabled an I/O throttling
node will be added into the graph.  When the feature is disabled, there
will be no I/O throttling node in the graph.

Stefan

pgpcj3rC8H0AW.pgp
Description: PGP signature