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