From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJSIh-00043Z-3J for qemu-devel@nongnu.org; Mon, 09 May 2011 11:23:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJSIf-0006qw-55 for qemu-devel@nongnu.org; Mon, 09 May 2011 11:23:11 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:37038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJSIf-0006qo-2U for qemu-devel@nongnu.org; Mon, 09 May 2011 11:23:09 -0400 Received: by gxk26 with SMTP id 26so2188030gxk.4 for ; Mon, 09 May 2011 08:23:08 -0700 (PDT) Message-ID: <4DC806D7.6090400@codemonkey.ws> Date: Mon, 09 May 2011 10:23:03 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DC7EEB0.3040007@redhat.com> In-Reply-To: <4DC7EEB0.3040007@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Kevin Wolf , jes sorensen , Marcelo Tosatti , qemu-devel , Avi Kivity , Stefan Hajnoczi On 05/09/2011 08:40 AM, Dor Laor wrote: > No patch here (sorry) but collection of thoughts about these features > and their potential building blocks. Please review (also on > http://wiki.qemu.org/Features/LiveBlockMigration) > > Future qemu is expected to support these features (some already > implemented): > > * Live block copy > > Ability to copy 1+ virtual disk from the source backing file/block > device to a new target that is accessible by the host. The copy > supposed to be executed while the VM runs in a transparent way. > > Status: code exists (by Marcelo) today in qemu but needs refactoring > due to a race condition at the end of the copy operation. We agreed > that a re-implementation of the copy operation should take place > that makes sure the image is completely mirrored until management > decides what copy to keep. Live block copy is growing on me. It can actually be used (with an intermediate network storage) to do live block migration. > > * Live snapshots and live snapshot merge > > Live snapshot is already incorporated (by Jes) in qemu (still need > qemu-agent work to freeze the guest FS). Live snapshot is unfortunately not really "live". It runs a lot of operations synchronously which will cause the guest to incur downtime. We really need to refactor it to truly be live. > * Copy on read (image streaming) > Ability to start guest execution while the parent image reside > remotely and each block access is replicated to a local copy (image > format snapshot) > > It should be nice to have a general mechanism that will be used for > all image formats. What about the protocol to access these blocks > over the net? We can reuse existing ones (nbd/iscsi). I think the image format is really the best place to have this logic. Of course, if we have live snapshot merge, we could use a temporary QED/QCOW2 file and then merge afterwards. > * Using external dirty block bitmap > > FVD has an option to use external dirty block bitmap file in > addition to the regular mapping/data files. > > We can consider using it for live block migration and live merge too. > It can also allow additional usages of 3rd party tools to calculate > diffs between the snapshots. > There is a big down side thought since it will make management > complicated and there is the risky of the image and its bitmap file > get out of sync. It's much better choice to have qemu-img tool to be > the single interface to the dirty block bitmap data. Does the dirty block bitmap need to exist outside of QEMU? IOW, if it goes away after a guest shuts down, is that problematic? I think it potentially greatly simplifies the problem which makes it appealing from my perspective. Regards, Anthony Liguori