From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDW5u-0006kq-IF for qemu-devel@nongnu.org; Tue, 20 Jan 2015 05:31:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDW5p-0000wY-Ao for qemu-devel@nongnu.org; Tue, 20 Jan 2015 05:31:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDW5p-0000wI-45 for qemu-devel@nongnu.org; Tue, 20 Jan 2015 05:31:29 -0500 Date: Tue, 20 Jan 2015 16:01:12 +0530 From: Amit Shah Message-ID: <20150120103112.GI31174@grmbl.mre> References: <1419604968-87437-1-git-send-email-agraf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1419604968-87437-1-git-send-email-agraf@suse.de> Subject: Re: [Qemu-devel] [PATCH v3 0/5] Migration Deciphering aid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: pbonzini@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de On (Fri) 26 Dec 2014 [15:42:43], Alexander Graf wrote: > Migration is a black hole to most people. One of the biggest reasons for > this is that its protocol is a secret, undocumented sauce of code rolling > around random parts of the QEMU code base. > > But what if we simply exposed the description of how the format looks like > alongside the actual migration stream? This is what this patch set does. > > It adds a new section that comes after the end of stream marker (so that it > doesn't slow down migration) that contains a JSON description of the device > state description. > > Along with this patch set also comes a python script that can read said JSON > from a migration dump and decipher the device state and ram contents of the > migration dump using it. > > With this, you can now fully examine all glorious details that go over the > wire when virtual machine state gets dumped, such as during live migration. > > We discussed the approach taken here during KVM Forum 2013. Originally, my idea > was to include a special device that contains the JSON data which can be enabled > on demand. Anthony suggested however to just always include the description data > after the end marker which I think is a great idea. > > Example decoded migration: http://csgraf.de/mig/mig.txt > Example migration description: http://csgraf.de/mig/mig.desc.txt > Presentation: https://www.youtube.com/watch?v=iq1x40Qsrew > Slides: https://www.dropbox.com/s/otp2pk2n3g087zp/Live%20Migration.pdf Nice to finally see this! I guess you have a v4 coming soon? Amit