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
>
>
>
>
next prev parent 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).