From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYjsa-0000G8-3V for qemu-devel@nongnu.org; Mon, 20 Jun 2011 15:11:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYjsY-0001Be-Ge for qemu-devel@nongnu.org; Mon, 20 Jun 2011 15:11:24 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:41013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYjsY-0001BE-A1 for qemu-devel@nongnu.org; Mon, 20 Jun 2011 15:11:22 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5KIxTUs023659 for ; Mon, 20 Jun 2011 14:59:29 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5KJBJCQ111408 for ; Mon, 20 Jun 2011 15:11:19 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5KFB7tC021263 for ; Mon, 20 Jun 2011 12:11:07 -0300 Message-ID: <4DFF9B4C.1080804@us.ibm.com> Date: Mon, 20 Jun 2011 14:11:08 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DF762A4.2040503@us.ibm.com> <4DFF4DD1.50502@redhat.com> <4DFF502A.9020400@codemonkey.ws> <4DFF84C9.8030909@redhat.com> In-Reply-To: <4DFF84C9.8030909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Tyler C Hicks , Corey C Bryant , qemu-devel@nongnu.org On 06/20/2011 12:35 PM, Avi Kivity wrote: > On 06/20/2011 04:50 PM, Anthony Liguori wrote: >> On 06/20/2011 08:40 AM, Avi Kivity wrote: >>> On 06/14/2011 04:31 PM, Corey Bryant wrote: >>>> - Starting Qemu with a backing file >>>> >>> >>> For this we could tell qemu that a file named "xyz" is available via fd >>> n, via an extension of the getfd command. >>> >>> For example >>> >>> (qemu) getfd path="/images/my-image.img" >>> (qemu) getfd path="/images/template.img" >>> (qemu) drive-add path="/images/my-image.img" >>> >>> The open() for my-image.img first looks up the name in the getfd >>> database, and finds it, so it returns the fd from there instead of >>> opening. It then opens the backing file ("template.img") and looks it up >>> again, and finds the second fd from the session. >> >> The way I've been thinking about this is: >> >> -blockdev id=hd0-back,file=fd:4,format=raw \ >> -blockdev file=fd:3,format=qcow2,backing=hd0-back >> >> While your proposal is clever, it makes me a little nervous about >> subtle security ramifications. > > It would need careful explanation in the management tool author's guide, > yes. > > The main advantage is generality. It doesn't assume that a file format > has just one backing file, and doesn't require new syntax wherever a > file is referred to indirectly. FWIW, with blockdev, we need options to control this all anyway. If you go back to my QCFG proposal, the parameters would actually be format specific, so if we had: -block file=fd:4,format=fancypantsformat,part0=hd0-back.part1,part1=hd0-back.part2... Regards, Anthony Liguori >