From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59335 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ot0bX-0007eR-IV for qemu-devel@nongnu.org; Tue, 07 Sep 2010 12:01:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ot0bU-0002ka-Bj for qemu-devel@nongnu.org; Tue, 07 Sep 2010 12:01:03 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:39891) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ot0bU-0002ju-8Q for qemu-devel@nongnu.org; Tue, 07 Sep 2010 12:01:00 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o87FgJwH017453 for ; Tue, 7 Sep 2010 11:42:19 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o87G0obF060882 for ; Tue, 7 Sep 2010 12:00:50 -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 o87G0orF004246 for ; Tue, 7 Sep 2010 13:00:50 -0300 Message-ID: <4C8661AD.2060903@linux.vnet.ibm.com> Date: Tue, 07 Sep 2010 11:00:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration References: <4C864118.7070206@linux.vnet.ibm.com> <4C864D65.6090004@redhat.com> <4C86510E.9010303@linux.vnet.ibm.com> <4C8653E9.2070905@redhat.com> <4C86560D.9030308@linux.vnet.ibm.com> <4C86584C.9070406@redhat.com> <4C865A7C.4050003@linux.vnet.ibm.com> <4C865CB5.8070508@redhat.com> In-Reply-To: <4C865CB5.8070508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "libvir-list@redhat.com" , qemu-devel , Stefan Hajnoczi On 09/07/2010 10:39 AM, Kevin Wolf wrote: > Am 07.09.2010 17:30, schrieb Anthony Liguori: > >> On 09/07/2010 10:20 AM, Kevin Wolf wrote: >> >>> Am 07.09.2010 17:11, schrieb Anthony Liguori: >>> >>>> Copy-on-read is, in many cases, a property of the backing file because >>>> it suggests that the backing file is either very slow or potentially >>>> volatile. >>>> >>>> >>> The simple copy-on-read without actively streaming the rest of the image >>> is not enough anyway for volatile backing files. >>> >>> >> But as a web site owner, it's extremely useful for me to associate >> copy-on-read with an image because it significantly reduces my bandwidth. >> >> I have a hard time believing this isn't a valuable use-case and not one >> that's actually pretty common. >> > As a web site user, I don't necessarily want you to control the > behaviour of my qemu. :-) > That's why I understand your argument about -blockdev and making sure all compat features can be overridden. I'm happy with that as a requirement.Okay, the only place I'm disagreeing slightly is that I think an image >> format should be able to request copy_on_read such that the default >> behavior if an explicit flag isn't specified is to do what the image >> suggests we do. >> > Maybe we can agree on that. I'm not completely decided yet if allowing > the image to contain such a hint is a good or a bad thing. > It's a tough space. We don't want to include crazy amounts of metadata (and basically become OVF) but there's metadata that we would like to have. backing_format is a good example. It's a suggestion and it's something you really want to let a user override. Regards, Anthony Liguori > Kevin >