From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb7si-00026O-NG for qemu-devel@nongnu.org; Mon, 27 Jun 2011 05:13:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qb7sd-0001TX-00 for qemu-devel@nongnu.org; Mon, 27 Jun 2011 05:13:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb7sc-0001TT-FP for qemu-devel@nongnu.org; Mon, 27 Jun 2011 05:13:18 -0400 Message-ID: <4E0849A6.4070009@redhat.com> Date: Mon, 27 Jun 2011 12:13:10 +0300 From: Dor Laor MIME-Version: 1.0 References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> <4DF9FBE4.9080300@redhat.com> <4DFA004E.9010001@redhat.com> <20110616145243.GB12173@amt.cnet> <20110616153018.GA20714@stefanha-thinkpad.localdomain> <20110617123152.GA7379@amt.cnet> <4DFE1D8C.3000402@redhat.com> <4E072B0B.4010105@redhat.com> <4E0835EB.9010505@redhat.com> In-Reply-To: <4E0835EB.9010505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Image streaming and live block copy Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Stefan Hajnoczi , jes sorensen , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Orit Wasserman , Avi Kivity , Adam Litke On 06/27/2011 10:48 AM, Kevin Wolf wrote: > Am 26.06.2011 14:50, schrieb Dor Laor: >> On 06/24/2011 12:28 PM, Stefan Hajnoczi wrote: >>> On Sun, Jun 19, 2011 at 5:02 PM, Dor Laor wrote: >>>> On 06/18/2011 12:17 PM, Stefan Hajnoczi wrote: >>>>> >>>>> On Sat, Jun 18, 2011 at 10:15 AM, Stefan Hajnoczi >>>>> wrote: >>>>>> >>>>>> On Fri, Jun 17, 2011 at 1:31 PM, Marcelo Tosatti >>>>>> wrote: >>>>>>> >>>>>>> On Thu, Jun 16, 2011 at 04:30:18PM +0100, Stefan Hajnoczi wrote: >>>>>>>> >>>>>>>> On Thu, Jun 16, 2011 at 11:52:43AM -0300, Marcelo Tosatti wrote: >>>>>>>> This approach does not use the backing file feature? >>>>>>>> >>>>>>>>> blkstream block driver: >>>>>>>>> >>>>>>>>> - Maintain in memory whether given block is allocated in local image, >>>>>>>>> if not, read from remote, write to local. Set block as local. >>>>>>>>> Local and remote simply two block drivers from image streaming driver >>>>>>>>> POV. >>>>>>>>> - Once all blocks are local, notify mgmt so it can switch to local >>>>>>>>> copy. >>>>>>>>> - Writes are mirrored to source and destination, minding guest writes >>>>>>>>> over copy writes. >>>>>>>> >>>>>>>> We open the remote file read-only for image streaming and do not want >>>>>>>> to >>>>>>>> mirror writes. >>>>>>> >>>>>>> Why not? Is there any disadvantage of mirroring writes? >>>>>> >>>>>> Think of the use case with a Fedora master image over NFS. You want a >>>>>> local clone of that master image and use the stream command to copy >>>>>> the data from the master image into the local clone. >>>>>> >>>>>> You cannot modify that master image because other VMs are using it too >>>>>> and/or you want to be able to clone new VMs from it in the future. >>>>> >>>>> BTW the workaround is to create two local images: >>>>> 1. Local clone with master image as a backing file. This is the live >>>>> block copy source image. >>>>> 2. Local image without a backing file. This is the live block copy >>>>> destination image. >>>>> >>>>> But this is not very elegant. Writes get mirrored so that crash recovery >>>>> works. >>>> >>>> There is an easier work around for image streaming using live block copy >>>> (mirror approach): >>>> - Create the dst VM as an empty new COW image of the src (even over >>>> the non shared storage, use some protocol tag for the src location >>>> like nbd://original_path/src_file_name) >>> >>> Migration and non-shared storage has come up a few times in this >>> discussion. But both live block copy and image streaming need access >>> to source and destination - they do not have explicit non-shared >>> storage support. I think non-shared and using nbd:// is orthogonal to >>> the discussion. Just want to check that you agree and I haven't >>> missed something? >> >> You're right, I was mainly trying to be as general as possible. > > I think there is one important point to consider for using NBD: You > always see a single image on the NBD client, which could in fact have a > backing file chain on the source. So bdrv_is_allocated() doesn't work > over NBD, which becomes interesting when you want to share a backing > file with the new copy. What is we'll use iscsi? Will the client have a matching iscsi verb to detect whether a certain block is in fact a unallocated and we'll be able to use this for our benefit? Of course it will make the non shared storage case more complex. > > Kevin > >