From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QaopL-0001DV-50 for qemu-devel@nongnu.org; Sun, 26 Jun 2011 08:52:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QaopJ-0008Vx-Kh for qemu-devel@nongnu.org; Sun, 26 Jun 2011 08:52:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QaopJ-0008Vm-1P for qemu-devel@nongnu.org; Sun, 26 Jun 2011 08:52:37 -0400 Message-ID: <4E072B91.4020206@redhat.com> Date: Sun, 26 Jun 2011 15:52:33 +0300 From: Dor Laor MIME-Version: 1.0 References: <4DFE1FEC.10207@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Image streaming gives live block copy for free (and vice versa) Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , "David P. Allan" , Jes Sorensen , Marcelo Tosatti , qemu-devel , Avi Kivity , Eric Blake On 06/24/2011 12:35 PM, Stefan Hajnoczi wrote: > On Sun, Jun 19, 2011 at 5:12 PM, Dor Laor wrote: >> On 06/17/2011 08:53 AM, Stefan Hajnoczi wrote: >>> >>> Perhaps someone has been saying this all along but I want to spell it >>> out that image streaming and live block copy are equivalent in theory. >>> I just realized this last night. In practice we might choose one >>> implementation or two different ones for performance reasons. >>> >>> If any of these are unclear please let me know and I'll try to post >>> diagrams. >>> >>> Live block copy using image streaming >>> ------------------------------------- >>> >>> 1. Create the destination image file and use the source image as the >>> backing file. >>> 2. Quiesce I/O and pause VM. >>> 3. Switch to destination image. >>> 4. Resume VM. >>> 5. Start streaming destination image in order to copy source image >>> data into destination file. >>> 6. Streaming completes and disables the backing file, leaving the live >>> copied destination image that no longer depends on the source image. >> >> Well streaming is copying just using post-copy approach. >> Both pre and post are required: >> - post-copy (aka streaming) for fast live block migration of the VM >> for cpu load balance. >> - pre-copy (aka live block copy) >> If you manage to get a network outage between the source and the >> destination storage systems, you will manage to keep running the VM >> on the source side. > > Out of interest, are you brainstorming using live block copy and image > streaming for pre- and post-copy live migration or do you have > concrete plans to update libvirt to use these mechanisms? Adding Eric, Daniel and Dave from the libvirt team. > > So far I've been focussing on the fast provisioning use case where > image streaming helps, but eventually I would like to improve the > state of storage migration too. In general it seems to me that we need to reuse the design so fast provision, live block migration, live snapshot (merge) and non shared storage option will all use the same code and the same interfaces. > > Stefan > > >