From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLie2-0002bA-Am for qemu-devel@nongnu.org; Sun, 15 May 2011 17:14:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLie1-0002Am-Ed for qemu-devel@nongnu.org; Sun, 15 May 2011 17:14:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLie1-0002AE-7V for qemu-devel@nongnu.org; Sun, 15 May 2011 17:14:33 -0400 Message-ID: <4DD04231.9010501@redhat.com> Date: Mon, 16 May 2011 00:14:25 +0300 From: Dor Laor MIME-Version: 1.0 References: <4DC7EEB0.3040007@redhat.com> <4DCBFDB2.6010801@redhat.com> <4DCCA278.1000508@sundar.org> In-Reply-To: <4DCCA278.1000508@sundar.org> 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 Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jagane Sundar Cc: Kevin Wolf , Anthony Liguori , Jes Sorensen , Marcelo Tosatti , qemu-devel , Avi Kivity , Stefan Hajnoczi On 05/13/2011 06:16 AM, Jagane Sundar wrote: > On 5/12/2011 8:33 AM, Jes Sorensen wrote: >> On 05/09/11 15:40, Dor Laor wrote: >>> Summary: >>> * We need Marcelo's new (to come) block copy implementation >>> * should work in parallel to migration and hotplug >>> * General copy on read is desirable >>> * Live snapshot merge to be implemented using block copy >>> * Need to utilize a remote block access protocol (iscsi/nbd/other) >>> Which one is the best? >>> * Keep qemu-img the single interface for dirty block mappings. >>> * Live block migration pre copy == live copy + block access protocol >>> + live migration >>> * Live block migration post copy == live migration + block access >>> protocol/copy on read. >>> >>> Comments? >> I think we should add Jagane Sundar's Livebackup to the watch list here. >> It looks very interesting as an alternative way to reach some of the >> same goals. >> >> Cheers, >> Jes > Thanks for the intro, Jes. I am very interested in garnering support for > Livebackup. > > You are correct in that Livebackup solves some, but not all, problems in > the same space. > > Some comments about my code: It took me about two months of development > before I connected with you on the list. > Initially, I started off by doing a dynamic block transfer such that > fewer and fewer blocks are dirty till there are no more dirty blocks and > we declare the backup complete. The problem with this approach was that > there was no real way to plug in a guest file system quiesce function. I > then moved on to the snapshot technique. With this snapshot technique I > am also able to test the livebackup function very thoroughly - I use a > technique where I create a LVM snapshot simultaneously, and do a cmp of > the LVM snapshot and the livebackup backup image. > > With this mode of testing, I am very confident of the integrity of my > solution. > > I chose to invent a new protocol that is very simple, and custom to > livebackup, because I needed livebackup specific functions such as > 'create snapshot', 'delete snapshot', etc. Also, I am currently > implementing SSL based encryption with both client authenticating to > server and server authenticating to client using self signed certificate. > iSCSI or NBD would be more standards compliant, I suppose. +1 that iScsi/NBD have better potential. > > My high level goal is to make this a natural solution for Infrastructure > As A Cloud environments. I am looking carefully at integrating the > management of the Livebackup function into Openstack. One important advantage of live snapshot over live backup is support of multiple (consecutive) live snapshots while there can be only a single live backup at one time. This is why I tend to think that although live backup carry some benefit (no merge required), the live snapshot + live merge are more robust mechanism. > > I would like to help in any way I can to make KVM be the *best* VM > technology for IaaS clouds. :) > > Thanks, > Jagane > > > >