From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOn9K-0004tV-AU for qemu-devel@nongnu.org; Tue, 24 May 2011 04:39:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOn9I-0002mL-QD for qemu-devel@nongnu.org; Tue, 24 May 2011 04:39:34 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:44946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOn9I-0002mD-Nj for qemu-devel@nongnu.org; Tue, 24 May 2011 04:39:32 -0400 Received: by gwb19 with SMTP id 19so2935154gwb.4 for ; Tue, 24 May 2011 01:39:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110523224925.GK969@shareable.org> References: <4DD6B777.9020800@us.ibm.com> <20110523094558.GA24143@redhat.com> <20110523103027.GD24143@redhat.com> <4DDA5A3C.1010500@codemonkey.ws> <20110523224925.GK969@shareable.org> Date: Tue, 24 May 2011 09:39:31 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Tyler C Hicks , Markus Armbruster , Corey Bryant On Mon, May 23, 2011 at 11:49 PM, Jamie Lokier wrote: > Markus Armbruster wrote: >> Anthony Liguori writes: >> >> > On 05/23/2011 05:30 AM, Daniel P. Berrange wrote: >> >> It feels to me that turning the current block driver code which just = does >> >> open(2) on files, into something which issues events& =A0asynchronous= ly >> >> waits for a file would potentially be quite complex. >> >> >> >> You also need to be much more careful from a security POV if the mgmt >> >> app is accepting requests to open arbitrary files from QEMU, to ensur= e >> >> the filenames are correctly/strictly validated before opening them an= d >> >> giving them back to QEMU. An architecture where the mgmt app decides >> >> what FDs to supply upfront, has less potential for security errors. >> >> >> >> To me the ideal would thus be that we can supply FDs for the backing >> >> store with -blockdev syntax, and that places where QEMU re-opens file= s >> >> would be enhanced to avoid that need. If there are things we can't do >> >> without closing& =A0re-opening the same file, then perhaps we need so= me >> >> new ioctl()/fcntl() calls to change those file attributes on the fly. >> > >> > I agree. =A0But my view of blockdev is that you wouldn't set an fd >> > attribute but rather the backing file name and use the fd protocol. >> > For instance: >> > >> > -blockdev id=3Dfoo-base,path=3Dfd:4,format=3Draw >> > -blockdev id=3Dfoo,path=3Dfd:3,format=3Dqcow2,backing_file=3Dfoo >> >> I guess you mean backing_file=3Dfoo-base. >> >> If none is specified, use the backing file specification stored in the >> image. >> >> Matches my current thinking. > > Being able to override the backing file path would be useful anyway. > > I've already had problems when moving established qcow2 files between > systems, that for historical reasons contain either an absolute path > inside for the backing file, or some messy "../../whatever", or > "foo/bar/whatever", or "backing.img" (lots of different ones with the > same name), all of which are a pain to work around. > > (Imho, it would also make sense if qcow2 files contained a UUID for > their backing file to verify you've given the correct backing file, > and maybe help find it (much like Linux finds real disk devices and > filesystems when mounting these days).) Try the qemu-img rebase -f command: qemu-img uses the unsafe mode if "-u" is specified. In this mode, only = the backing file name and format of filename is changed without any checks on the file contents. The user must take care of specifying the correct new ba= cking file, or the guest-visible content of the image will be corrupted. This mode is useful for renaming or moving the backing file to somewher= e else. It can be used without an accessible old backing file, i.e. you = can use it to fix an image whose backing file has already been moved/rename= d. Stefan