From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWZhs-00040o-0g for qemu-devel@nongnu.org; Tue, 14 Jun 2011 15:55:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWZhm-0000Wx-0X for qemu-devel@nongnu.org; Tue, 14 Jun 2011 15:55:23 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:54576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWZhl-0000WJ-HN for qemu-devel@nongnu.org; Tue, 14 Jun 2011 15:55:17 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5EJV5q4019981 for ; Tue, 14 Jun 2011 15:31:05 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5EJtDrY116520 for ; Tue, 14 Jun 2011 15:55:13 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5EJtDS3014062 for ; Tue, 14 Jun 2011 15:55:13 -0400 Message-ID: <4DF7BC9F.10506@us.ibm.com> Date: Tue, 14 Jun 2011 15:55:11 -0400 From: Corey Bryant MIME-Version: 1.0 References: <4DF762A4.2040503@us.ibm.com> <4DF788AF.3010103@redhat.com> In-Reply-To: <4DF788AF.3010103@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 12:13 PM, Eric Blake wrote: > On 06/14/2011 07:31 AM, Corey Bryant wrote: >> > - Starting Qemu with a backing file > What do you mean by this? Taking a guess: > > In the case of a qcow2 image with a backing file, does that mean that > both the qcow2 image and it's backing file can both be passed to qemu > via fd: notations? That is, if the -drive file=fd:4,format=qcow2 option > is passed, and fd4 is a qcow2 image that also has a backing file, it > seems like libvirt should also be able to pass that backing file via > another fd, so that qemu doesn't have to open() the backing file > directly. 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. > > -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization > library http://libvirt.org 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?