From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliRK-00024w-JO for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:16:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QliRI-0001Xb-Vz for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:16:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliRI-0001XX-M3 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:16:52 -0400 Message-ID: <4E2ECCFC.7050508@redhat.com> Date: Tue, 26 Jul 2011 16:19:40 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1311684710-27074-1-git-send-email-coreyb@linux.vnet.ibm.com> <4E2EC897.2090801@redhat.com> In-Reply-To: <4E2EC897.2090801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v3] 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, aliguori@us.ibm.com, Corey Bryant , qemu-devel@nongnu.org, tchicks@us.ibm.com Am 26.07.2011 16:00, schrieb Eric Blake: > On 07/26/2011 06:51 AM, Corey Bryant wrote: >> There are some additional features provided by certain image types >> where Qemu reopens the image file. All of these scenarios will be >> unsupported for the fd: protocol, at least for this patch: >> >> - The -snapshot command line option >> - The savevm monitor command >> - The snapshot_blkdev monitor command >> - Use of copy-on-write image files >> - The -cdrom command line option >> - The -drive command line option with media=cdrom >> - The change monitor command >> >> The thought is that this support can be added in the future, but is >> not required for the initial fd: support. > > Libvirt will eventually need support for fd passing on savevm, > snapshot_blkdev, and change monitor commands, as well as for -cdrom, > before this feature can be used to provide the desired security > enhancements. I agree that for an incremental patch, you don't have to > solve all points at once, but until all places have been modified to > support fd usage, you aren't gaining any security, except for severely > constrained guests. > > Furthermore, how do you plan to map fd: to filename? There's already > been big threads on why snapshot_blkdev needs both the new fd: and the > name of the old backing file at the same time, so that qemu can write > the correct headers into new qcow2 files. That's a problem to solve in snapshot_blkdev, not in -drive. In general qemu doesn't need and shouldn't know the file name if it's meant to use an fd. Kevin