From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8ou8-0003bQ-PU for qemu-devel@nongnu.org; Mon, 12 Aug 2013 05:59:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8ou2-0001eB-VU for qemu-devel@nongnu.org; Mon, 12 Aug 2013 05:59:12 -0400 Received: from mail-ee0-x236.google.com ([2a00:1450:4013:c00::236]:53548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8ou2-0001dw-OV for qemu-devel@nongnu.org; Mon, 12 Aug 2013 05:59:06 -0400 Received: by mail-ee0-f54.google.com with SMTP id e53so3399090eek.27 for ; Mon, 12 Aug 2013 02:59:05 -0700 (PDT) Date: Mon, 12 Aug 2013 11:59:03 +0200 From: Stefan Hajnoczi Message-ID: <20130812095903.GF29880@stefanha-thinkpad.redhat.com> References: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> 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" , fred.konrad@greensocs.com, xiawenc@linux.vnet.ibm.com, "avi@redhat.com" On Fri, Aug 09, 2013 at 10:20:49AM +0000, Chijianchun wrote: > 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? A few people have looked at live vmsave or guest RAM snapshots. The idea that was discussed on qemu-devel@nongnu.org uses fork(2) to capture the state of guest RAM and then send it back to the parent process. The guest is only paused for a brief instant during fork(2) and can continue to run afterwards. The child process is a simple loop that sends the contents of guest RAM back to the parent process over a pipe or writes the memory pages to the save file on disk. It performs no logic besides writing out guest RAM. Stefan