qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC]VM live snapshot proposal


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal
Date: Mon, 3 Mar 2014 13:55:20 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 03.03.2014 um 13:32 hat Stefan Hajnoczi geschrieben:
> On Mon, Mar 03, 2014 at 01:13:41AM +0000, Huangpeng (Peter) wrote:
> 
> Just to summarize the idea of live savevm for people joining the
> discussion:
> 
> It should be possible to save a snapshot of the guest (including memory,
> devices, and disk) without noticable downtime.
> 
> The 'savevm' command pauses the guest until the snapshot has been
> completed and therefore doesn't meet the requirements.
> 
> > Here I have another proposal, based on the live-migration scheme, add 
> > consistent 
> > memory state tracking and saving.
> > The idea is simple:
> > 1.First round use live-migration to save all memory to a snapshot file.
> > 2.intercept the action of memory-modify, save old pages to a temporary file 
> > and mark dirty-bits,
> > 3.Merge temporary file to the original snapshot file

Why do you need a temporary file for this? Couldn't you directly store
the memory to its final destination in the snapshot file?

> > Detailed process:
> > (1)Pause VM
> > (2) Save the device status to a temporary file (live-migration already 
> > supported )
> > (3) Make disk snapshot
> > (4) Enable page dirty log and old dirty pages save function(which we need 
> > to add)
> > (5) Resume VM
> > (6) Begin the first round of iteration, we save the entire contents of the 
> > VM memory pages
> > to the snapshot file
> > (7) In the second round of iteration , we save the old page to the snapshot 
> > file
> > (8) Merge data of device status which is pre-saved in temporary files to 
> > the snapshot file
> > (8) End ram snapshot and some cleanup work
> > 
> > Due to memory-modifications may happen in kvm, qemu, or vhost, the key-part 
> > is how we
> > can provide common page-modify-tracking-and-saving api, we completed a 
> > prototype by 
> > simply add modified-page tracking/saving function in qemu, and it seems 
> > worked fine.
> 
> Yes, this is the tricky part.  To be honest, I think this is the reason
> no one has submitted patches - it's a hard task and the win isn't that
> great (you can already migrate to file).

So why don't we simply reuse the existing migration code?

Kevin



reply via email to

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