From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKUHe-0002z6-6j for qemu-devel@nongnu.org; Mon, 03 Mar 2014 09:56:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKUHY-0002rt-7h for qemu-devel@nongnu.org; Mon, 03 Mar 2014 09:55:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKUHX-0002rd-Uv for qemu-devel@nongnu.org; Mon, 03 Mar 2014 09:55:52 -0500 Date: Mon, 3 Mar 2014 14:55:35 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20140303145535.GE2837@work-vm> References: <615092B2FD0E7648B6E4B43E029BCFB84D578044@SZXEMA503-MBS.china.huawei.com> <20140303123234.GC21055@stefanha-thinkpad.redhat.com> <20140303125520.GF4850@dhcp-200-207.str.redhat.com> <53148169.6060700@redhat.com> <20140303133034.GI4850@dhcp-200-207.str.redhat.com> <531487F3.9010606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531487F3.9010606@redhat.com> Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Andrea Arcangeli , Pavel Hrdina , Zhanghailiang , KVM devel mailing list , Stefan Hajnoczi , "Huangpeng (Peter)" , mrhines@linux.vnet.ibm.com, "qemu-devel@nongnu.org" , Wenchao Xia * Paolo Bonzini (pbonzini@redhat.com) wrote: > Il 03/03/2014 14:30, Kevin Wolf ha scritto: > >> > So why don't we simply reuse the existing migration code? > >> I think this is different in the same way that block-backup and > >> block-mirror are different. Huangpeng's proposal would let you make > >> a consistent snapshot of disks and RAM. > >Right. Though the point isn't about consistency (doing the disk snapshot > >when memory has converged would be consistent as well), but about > >having the snapshot semantically right at the time when the monitor > >command is issued instead of only starting it then and being consistent > >at the point of completion. > > Right---though it's not entirely true that migration only affects > the point in time where you have consistency. For example, with > migration you cannot use the guest agent for freeze/thaw and, even > if we changed the code to allow that, the pause would be much longer > than for live snapshots or block-backup. > > >This is indeed like pre/post-copy live migration, and probably both > >options have their uses. I would suggest starting with the easy one, and > >adding the post-copy feature on top. > > The feature matrix for migration and snapshot > > disk RAM internal snapshot > non-live yes (0) yes (0) yes > live, disk only yes (1) N/A yes (2) > live, pre-copy yes (3) yes no > live, post-copy yes (4) no no > live, point-in-time yes (5) no no > > (0) just stop VM while doing normal pre-copy migration > (1) blockdev-snapshot-sync > (2) blockdev-snapshot-internal-sync > (3) block-stream > (4) drive-mirror > (5) drive-backup > > By "the easy one" you mean live savevm with snapshot at the end of > RAM migration, I guess. But the functionality is already available > using migration, while point-in-time snapshots actually add new > functionality. I'm not sure what's the status of the kernel > infrastructure for post-copy. Andrea? Accumulating the running set of changes that migration is spitting out gets you some of the way - but to do it you have to have points in the migration stream which represent a consistent view of device state, RAM and disk and I think the tricky point is getting those consistent points; while the CPU is running the set of pages that migration spits out are certainly newer than old versions of the pages but I don't think you can just put a marker in and say that the point represents a single consistent view of RAM. In many ways this is the opposite of Michael Hines's microcheckpointing approach; which stops everything and takes the snapshot regularly; I did suggest a modification to that would be to COW those checkpoints. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK