From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [RFC]VM live snapshot proposal Date: Mon, 3 Mar 2014 13:55:20 +0100 Message-ID: <20140303125520.GF4850@dhcp-200-207.str.redhat.com> References: <615092B2FD0E7648B6E4B43E029BCFB84D578044@SZXEMA503-MBS.china.huawei.com> <20140303123234.GC21055@stefanha-thinkpad.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Huangpeng (Peter)" , Paolo Bonzini , "qemu-devel@nongnu.org" , Wenchao Xia , Pavel Hrdina , KVM devel mailing list , Zhanghailiang To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48849 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754381AbaCCMzh (ORCPT ); Mon, 3 Mar 2014 07:55:37 -0500 Content-Disposition: inline In-Reply-To: <20140303123234.GC21055@stefanha-thinkpad.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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