From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYiNf-0007c5-8p for qemu-devel@nongnu.org; Mon, 20 Jun 2011 13:35:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYiNd-00082p-LV for qemu-devel@nongnu.org; Mon, 20 Jun 2011 13:35:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYiNd-00082a-6e for qemu-devel@nongnu.org; Mon, 20 Jun 2011 13:35:21 -0400 Message-ID: <4DFF84C9.8030909@redhat.com> Date: Mon, 20 Jun 2011 20:35:05 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DF762A4.2040503@us.ibm.com> <4DFF4DD1.50502@redhat.com> <4DFF502A.9020400@codemonkey.ws> In-Reply-To: <4DFF502A.9020400@codemonkey.ws> 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: Anthony Liguori Cc: libvir-list@redhat.com, Anthony Liguori , Corey Bryant , Tyler C Hicks , qemu-devel@nongnu.org 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. -- error compiling committee.c: too many arguments to function