qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dor Laor <dlaor@redhat.com>
To: Jagane Sundar <jagane@sundar.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Jes Sorensen <Jes.Sorensen@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: Mon, 16 May 2011 00:14:25 +0300	[thread overview]
Message-ID: <4DD04231.9010501@redhat.com> (raw)
In-Reply-To: <4DCCA278.1000508@sundar.org>

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
>
>
>
>

  reply	other threads:[~2011-05-15 21:14 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
2011-05-15 21:14     ` Dor Laor [this message]
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=4DD04231.9010501@redhat.com \
    --to=dlaor@redhat.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=jagane@sundar.org \
    --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).