qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration


From: Dor Laor
Subject: Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration
Date: Mon, 16 May 2011 00:14:25 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 ThunderBrowse/3.3.5

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 via email to

[Prev in Thread] Current Thread [Next in Thread]