From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYKSP-00012v-UZ for qemu-devel@nongnu.org; Sun, 19 Jun 2011 12:02:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYKSN-00085f-N8 for qemu-devel@nongnu.org; Sun, 19 Jun 2011 12:02:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYKSN-00085b-96 for qemu-devel@nongnu.org; Sun, 19 Jun 2011 12:02:39 -0400 Message-ID: <4DFE1D8C.3000402@redhat.com> Date: Sun, 19 Jun 2011 19:02:20 +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> In-Reply-To: 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: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , jes sorensen , Marcelo Tosatti , qemu-devel@nongnu.org, Avi Kivity , Adam Litke 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) - Run the usual live block copy of src image (master read only OS template) to the destination. - Use a -src-read-only flag that will make the copy skip the src writing. Voila - no duplicate writes, crash recovery works since we reference the original image and we share the code. > > Compare that to image streaming, which works across crash and doesn't > duplicate I/O. > > Stefan >