From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKlqF-0000bq-CD for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:40:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKlq8-0002CQ-Ey for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:40:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59586) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKlq7-0002CF-Ut for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:40:44 -0500 Date: Tue, 4 Mar 2014 09:40:32 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20140304094031.GC2711@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> <615092B2FD0E7648B6E4B43E029BCFB84D57953F@SZXEMA503-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <615092B2FD0E7648B6E4B43E029BCFB84D57953F@SZXEMA503-MBS.china.huawei.com> Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Huangpeng (Peter)" Cc: Kevin Wolf , Pavel Hrdina , Zhanghailiang , KVM devel mailing list , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Paolo Bonzini , Wenchao Xia * Huangpeng (Peter) (peter.huangpeng@huawei.com) wrote: > > > 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. > > > > 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. > > > > Good suggestion, The latest patches of post-copy seems updated 2 years ago. > https://github.com/yamahata/qemu I'm working on post-copy at the moment, using Andrea's kernel code, using bits of Yamahata's code base as well; hopefully it won't be too long until we have something to post. > One question: > Can post-copy fallback if exceptions happen during post-copy? What do you mean by 'exceptions' here? Generally postcopy can't fall back to precopy because once you're in postcopy mode the state is split between the two machines. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK