qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jagane Sundar <jagane@sundar.org>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	"dlaor@redhat.com" <dlaor@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>,
	Stefan Hajnoczi <stefan.hajnoczi@uk.ibm.com>
Subject: Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration
Date: Thu, 12 May 2011 20:16:08 -0700	[thread overview]
Message-ID: <4DCCA278.1000508@sundar.org> (raw)
In-Reply-To: <4DCBFDB2.6010801@redhat.com>

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.

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.

I would like to help in any way I can to make KVM be the *best* VM 
technology for IaaS clouds.

Thanks,
Jagane

  reply	other threads:[~2011-05-13  3:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-09 13:40 [Qemu-devel] [RFC] live snapshot, live merge, live block migration Dor Laor
2011-05-09 15:23 ` Anthony Liguori
2011-05-09 20:58   ` Dor Laor
2011-05-12 14:18   ` Marcelo Tosatti
2011-05-12 15:37   ` Jes Sorensen
2011-05-10 14:13 ` Marcelo Tosatti
2011-05-12 15:33 ` Jes Sorensen
2011-05-13  3:16   ` Jagane Sundar [this message]
2011-05-15 21:14     ` Dor Laor
2011-05-15 21:38       ` Jagane Sundar
2011-05-16  7:53         ` Dor Laor
2011-05-16  8:23           ` Jagane Sundar
2011-05-17 22:53             ` Dor Laor
2011-05-18 15:49               ` Jagane Sundar
2011-05-20 12:19 ` Stefan Hajnoczi
2011-05-20 12:39   ` Jes Sorensen
2011-05-20 12:49     ` Stefan Hajnoczi
2011-05-20 12:56       ` Jes Sorensen
2011-05-22  9:52   ` Dor Laor
2011-05-23 13:02     ` Stefan Hajnoczi
2011-05-27 16:46       ` Stefan Hajnoczi
2011-05-27 17:16         ` Jagane Sundar
2011-05-23  5:42   ` Jagane Sundar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DCCA278.1000508@sundar.org \
    --to=jagane@sundar.org \
    --cc=Jes.Sorensen@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefan.hajnoczi@uk.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).