From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC]VM live snapshot proposal Date: Mon, 03 Mar 2014 14:47:31 +0100 Message-ID: <531487F3.9010606@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , "Huangpeng (Peter)" , "qemu-devel@nongnu.org" , Wenchao Xia , Pavel Hrdina , KVM devel mailing list , Zhanghailiang , Andrea Arcangeli To: Kevin Wolf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8394 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753545AbaCCNrs (ORCPT ); Mon, 3 Mar 2014 08:47:48 -0500 In-Reply-To: <20140303133034.GI4850@dhcp-200-207.str.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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