From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWbL9-000139-0L for qemu-devel@nongnu.org; Tue, 14 Jun 2011 17:40:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWbL7-0003bd-4x for qemu-devel@nongnu.org; Tue, 14 Jun 2011 17:40:02 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:42887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWbL6-0003bT-N7 for qemu-devel@nongnu.org; Tue, 14 Jun 2011 17:40:00 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5ELN4CN012149 for ; Tue, 14 Jun 2011 15:23:04 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5ELdWCE220818 for ; Tue, 14 Jun 2011 15:39:42 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5ELdVE8013530 for ; Tue, 14 Jun 2011 15:39:31 -0600 Message-ID: <4DF7D512.5010909@us.ibm.com> Date: Tue, 14 Jun 2011 17:39:30 -0400 From: Corey Bryant MIME-Version: 1.0 References: <4DF762A4.2040503@us.ibm.com> <4DF788AF.3010103@redhat.com> <4DF7BC9F.10506@us.ibm.com> <4DF7C206.2000901@redhat.com> In-Reply-To: <4DF7C206.2000901@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v2] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: libvir-list@redhat.com, Anthony Liguori , qemu-devel@nongnu.org, Tyler C Hicks On 06/14/2011 04:18 PM, Eric Blake wrote: > On 06/14/2011 01:55 PM, Corey Bryant wrote: >>> >> So we would need something like -drive >>> >> file=fd:4,format=qcow2,backing=fd:5 >>> >> >>> >> and since backing files can be nested, we'd need some way of specifying >>> >> more than one level of backing file. Libvirt already knows how to walk >>> >> a chain of backing images in qcow2 files (it has to, in order to set >>> >> sVirt SELinux permissions on all of those files so that qemu can open() >>> >> each file), so it wouldn't be much harder for libvirt to instead do the >>> >> open() and pass each fd. >>> >> >> > Right. So what I was talking about here (and poorly stated) is that >> > starting Qemu with a copy-on-write image file causes a reopen of the >> > backing file. In this case you would only be passing the fd of the >> > copy-on-write file to Qemu. I've fenced that off as unsupported for now. >> > >> > I like your approach for passing multiple fds. Do you think backing file >> > support is needed immediately with this patch? > Incremental support is fine by me, but we'll need it sooner or later. > And for the nested backing file case, does: > > -drive file=fd:4,format=qcow2,backing=fd:5,backing=fd:6 > > work, or would we need: > > -drive file=fd:4,format=qcow2,backing1=fd:5,backing2=fd:6 > > That is, can you have more than one backing=, or do you need distinct > backingN=, and if you have to support multiple N, we must make sure the > solution allows arbitrarily deep nesting (or at least as deep as any > current limits qemu places on qcow2 backing file nesting). Qemu currently opens the specified copy-on-write file, finds a backing file name in the opened file's header, opens that backing file, and repeats. So it seems that either a backingN= would be needed or a way to map a file descriptor to the file name in the header. I think the latter is along the lines of what was discussed here with -blockdev: http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02417.html Repeating the syntax specified in that thread, you'd have: -blockdev id=foo-base,path=fd:4,format=raw -blockdev id=foo,path=fd:3,format=qcow2,backing_file=foo-base where id is the file name. This chains the backing files on the command line. Corey