From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj1cF-0007UE-QQ for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:59:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj1cC-0002sW-HP for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:59:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj1cC-0002sL-Cm for qemu-devel@nongnu.org; Mon, 05 Oct 2015 04:59:24 -0400 Date: Mon, 5 Oct 2015 14:29:21 +0530 From: Amit Shah Message-ID: <20151005085921.GF21612@grmbl.mre> References: <20150915103909.GD10281@grmbl.mre> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC 0/3] Checkpoint-assisted migration proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Knauth Cc: Bohdan Trach , quintela@redhat.com, Bohdan Trach , qemu-devel@nongnu.org On (Mon) 05 Oct 2015 [10:33:01], Thomas Knauth wrote: > Hi Amit, > > On Tue, Sep 15, 2015 at 12:39 PM, Amit Shah wrote: > > Could you please include a file in the docs/ directory that documents > > how this works, so it's easier to comment on the general idea? > > sure, we will add this. Thanks! > > From 'checkpointing', I was afraid this was going to use some > > checkpoint-restore framework, but instead it's a new checkpointing > > method that you're adding to qemu. > > > > Can you describe when checkpoints are taken, and what is checkpointed? > > How is it stored on the disk? > > Checkpoints are taken after a migration (at the source). If a > checkpoint exists at the destination, the VM's state is reconstructed > from the local checkpoint as well as updated pages from the source. > This checkpoint-assisted migration can be faster, if network is the > bottleneck, and saves network bandwidth. > > We can, in principle, reuse the existing checkpoint format of QEMU. > The current implementation writes its own checkpoint because it was > less effort on our side. We write the VM's main memory into a single > file. > > > I'm sure the patches have all the details, but it's easier to check > > the soundness of the idea if there's a high-level doc that explains > > this, and then we can discuss the finer points over patches. > > We've recently published a paper about the general idea and expected > benefits for a number of workloads ( > http://se.inf.tu-dresden.de/pubs/papers/knauth2015vecycle.pdf ) I'll give it a look, thanks. I'm interested in knowing what workloads benefit. There was one outstanding question from Dave about collisions: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg01614.html Can you please address that in your next submission? > > Overall, I think this approach can benefit some workloads, and since > > it's not affecting a lot of common code, we could look at adding it. > > > > Also, apologies for not getting to this earlier. > > Kind regards, > Thomas. Thanks, Amit