From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxbU8-0005U9-24 for qemu-devel@nongnu.org; Thu, 19 Jun 2014 08:30:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxbU1-00055z-TE for qemu-devel@nongnu.org; Thu, 19 Jun 2014 08:30:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxbU1-000550-Lv for qemu-devel@nongnu.org; Thu, 19 Jun 2014 08:30:25 -0400 Date: Thu, 19 Jun 2014 08:30:19 -0400 From: Jeff Cody Message-ID: <20140619123019.GA6096@localhost.localdomain> References: <526da734a5f3cffd2eb56accafdb4add38c75270.1403041699.git.jcody@redhat.com> <20140619085502.GR21236@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140619085502.GR21236@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 for 2.1 01/10] block: Auto-generate node_names for each BDS entry List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com 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 > > Signed-off-by: Jeff Cody > > --- > > 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? 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. > > 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. 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.