From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXsyw-0002xm-Ba for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:00:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXsyt-0000pK-2R for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:00:34 -0400 Received: from smtp3.mundo-r.com ([212.51.32.191]:64232 helo=smtp4.mundo-r.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXsys-0000ox-SU for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:00:31 -0400 Date: Tue, 17 Mar 2015 16:00:28 +0100 From: Alberto Garcia Message-ID: <20150317150028.GA21771@igalia.com> References: <49b845c4a362ffd64ec78bbe0b165cd7addd2a4b.1424439295.git.berto@igalia.com> <20150305140958.GE5427@noname.redhat.com> <20150311163806.GA5883@igalia.com> <20150312154517.GB7029@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150312154517.GB7029@noname.redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add QMP support for streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi On Thu, Mar 12, 2015 at 04:45:17PM +0100, Kevin Wolf wrote: > > One issue that I'm finding is that when we move the block-stream > > job to an intermediate node, where the device name is empty, we > > get messages like "Device '' is busy". > > > > I can use node names instead, but they are also not guaranteed to > > exist. > My first thought was "then make it 'Source/Target device is busy' > without mentioning any name". In the context of any given command, > it would still be clear which BDS is meant. There's a related problem that I discussed on IRC with Kevin and Eric but that I think needs further deliberation. The BlockJobInfo object returned by query-block-jobs identifies the owner of the job using the 'device' field. If jobs can be in any intermediate node then we cannot simply rely on the device name. We also cannot simply replace it with a node name because 1) it might not exist and 2) existing libvirt versions expect a device name. So I see several alternatives: a) Add a new 'node-name' field to BlockJobInfo. It's simple, 'device' keeps the current semantics so we don't break compatibility. b) Make 'device' return the device name as it currently does, or the node name if it's not present. The main problem is that libvirt cannot easily know what to expect. On the other hand since both device and node-name share the same namespace the returned value is not ambiguous. c) Make 'device' return the same name that was used when the job was created. It's maybe simpler for libvirt than option b), but it would require us to remember how the job was created, possibly in the BlockJob structure. This is personally my least favorite option. d) Create a new query command that returns a different data structure. I would opt for a) or b), but I'd like to hear if you have a different opinion. Regarding the 'block-stream' command, I think the current option to reuse the 'device' parameter to refer to either a device or a node name is ok, so I'll go forward with that one. > On the other hand, having an owner BDS for a block job is considered > a mistake meanwhile because there is no clear rule which BDS to pick > when the job involves more than one. Does it really matter as long as all the operations blockers are correctly set? > In fact, without tying a job to a BDS, it could be just a background > job instead of specifically a block job. I don't understand what you mean by this. Berto