From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7omE-0000ar-QL for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:39:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7om6-0001LU-CS for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:38:54 -0400 Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:34078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7om6-0001LO-5m for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:38:46 -0400 Received: by mail-ee0-f50.google.com with SMTP id d51so2230858eek.9 for ; Fri, 09 Aug 2013 08:38:45 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <52050CE4.6000306@redhat.com> Date: Fri, 09 Aug 2013 17:38:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> In-Reply-To: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Are there plans to achieve ram live Snapshot feature? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chijianchun Cc: "aliguori@us.ibm.com" , "kvm@vger.kernel.org" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "paul@codesourcery.com" , "avi@redhat.com" Il 09/08/2013 12:20, Chijianchun ha scritto: > Now in KVM, when RAM snapshot, vcpus needs stopped, it is Unfriendly > restrictions to users. > > Are there plans to achieve ram live Snapshot feature? > > in my mind, Snapshots can not occupy additional too much memory, So when > the memory needs to be changed, the old memory page is needed to flush > to the file first. But flushing to file is too slower than memory, and > when flushing, the vcpu or VM is need to be paused until finished > flushing, so pause...resume...pause...resume............., more and > more slower. > > Is this idea feasible? Are there any other thoughts? > This looks very similar to postcopy migration (you can Google it). The infrastructure for postcopy migration could be used for this as well. Paolo