From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKTDl-0006HV-UC for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:47:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKTDf-0004ZS-VV for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:47:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKTDf-0004Z4-Kz for qemu-devel@nongnu.org; Mon, 03 Mar 2014 08:47:47 -0500 Message-ID: <531487F3.9010606@redhat.com> Date: Mon, 03 Mar 2014 14:47:31 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20140303133034.GI4850@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Andrea Arcangeli , Pavel Hrdina , Zhanghailiang , KVM devel mailing list , Stefan Hajnoczi , "Huangpeng (Peter)" , "qemu-devel@nongnu.org" , Wenchao Xia 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? Paolo