From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [RFC]VM live snapshot proposal Date: Mon, 3 Mar 2014 14:30:34 +0100 Message-ID: <20140303133034.GI4850@dhcp-200-207.str.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Hajnoczi , "Huangpeng (Peter)" , "qemu-devel@nongnu.org" , Wenchao Xia , Pavel Hrdina , KVM devel mailing list , Zhanghailiang To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23614 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753873AbaCCNbD (ORCPT ); Mon, 3 Mar 2014 08:31:03 -0500 Content-Disposition: inline In-Reply-To: <53148169.6060700@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 03.03.2014 um 14:19 hat Paolo Bonzini geschrieben: > Il 03/03/2014 13:55, Kevin Wolf ha scritto: > >>>> > Due to memory-modifications may happen in kvm, qemu, or vhost, the key-part is how we > >>>> > can provide common page-modify-tracking-and-saving api, we completed a prototype by > >>>> > simply add modified-page tracking/saving function in qemu, and it seems worked fine. > >>> > >>> Yes, this is the tricky part. To be honest, I think this is the reason > >>> no one has submitted patches - it's a hard task and the win isn't that > >>> great (you can already migrate to file). > >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. 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. Kevin