From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiK1O-0008Ls-EG for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:54:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiK1K-0002Z5-W8 for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:54:14 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:37685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiK1K-0002Yg-Oo for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:54:10 -0400 Received: by widdi4 with SMTP id di4so53561602wid.0 for ; Wed, 15 Apr 2015 02:54:09 -0700 (PDT) Date: Wed, 15 Apr 2015 10:54:05 +0100 From: Stefan Hajnoczi Message-ID: <20150415095405.GE16656@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fWddYNRDgTk9wQGZ" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] feature proposal: checkpoint-assisted migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Knauth Cc: Bohdan Trach , qemu-devel@nongnu.org --fWddYNRDgTk9wQGZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 14, 2015 at 01:20:33PM +0200, Thomas Knauth wrote: > In the course of our research we implemented a prototype of this > feature within kvm/qemu. We would like to contribute it to mainline, > but it needs cleanup and proper testing. As is the nature with > research prototypes, the code is ugly and not well integrated with the > existing kvm/qemu codebase. To avoid confusion and irritation, I want > to mention that I have little experience in contributing to large > open-source projects. So if I violate some unwritten protocol or best > practises, please be patient. Guidelines for contributing patches are here: http://qemu-project.org/Contribute/SubmitAPatch Regarding the idea, it sounds like it could be beneficial for some migration use cases. I've thought about an rsync approach for disk images, and that is similar to your idea for RAM. There are image file formats that keep generation counts for regions of the disk image, making it quick to find out which regions have changed between two images. Stefan --fWddYNRDgTk9wQGZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVLjU9AAoJEJykq7OBq3PI9j0IAJDPIV0memtuv7VpyQ/GyR17 Qet9fXEoeglzyAOrxCbjIUAWmPTbO/xteb3zVh47wacHcNhkOAPpXFs+422BSV6g /tkR10h2HHNJGaEw+ywA1Mp3ibHyfAO5YoxNa2olm6dFHdGCqyplHbyJCuUKccO6 HPerXkz3MFnDJ73I9HWm3vz9hGDSNz8Ni0HkPiuHzuYhMeebT9MhbqyyelgDncE/ +xrWotSDRAEYeo+7zEPYAcVRII4WhzqmWiN3l/Wed3vbGBdFt3LFfHZwSHg94HYJ ThSCMUOm/daKhwoKTfWfF0fxikyWS97JHEkXenYYDvujsQYBA71QK5XCXzXV2Lg= =UTV6 -----END PGP SIGNATURE----- --fWddYNRDgTk9wQGZ--