From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9QIm-0001d4-Cm for qemu-devel@nongnu.org; Tue, 13 Aug 2013 21:55:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9QIf-0001m8-4w for qemu-devel@nongnu.org; Tue, 13 Aug 2013 21:55:08 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:36459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9QIe-0001lj-Fx for qemu-devel@nongnu.org; Tue, 13 Aug 2013 21:55:01 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Aug 2013 11:46:26 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id C81F22CE8052 for ; Wed, 14 Aug 2013 11:54:34 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7E1sLt410813910 for ; Wed, 14 Aug 2013 11:54:24 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7E1sVjP026338 for ; Wed, 14 Aug 2013 11:54:32 +1000 Message-ID: <520AE34D.8000002@linux.vnet.ibm.com> Date: Wed, 14 Aug 2013 09:54:21 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com> <20130812095903.GF29880@stefanha-thinkpad.redhat.com> <232DEBC1058FA4A5BD76D16A@Ximines.local> <52099FA3.6010207@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Stefan Hajnoczi Cc: Anthony Liguori , kvm , Paul Brook , Marcelo Tosatti , qemu-devel , Chijianchun , Avi Kivity , Alex Bligh , fred.konrad@greensocs.com 于 2013-8-13 16:21, Stefan Hajnoczi 写道: > On Tue, Aug 13, 2013 at 4:53 AM, Wenchao Xia wrote: >> 于 2013-8-12 19:33, Stefan Hajnoczi 写道: >> >>> On Mon, Aug 12, 2013 at 12:26 PM, Alex Bligh wrote: >>>> >>>> --On 12 August 2013 11:59:03 +0200 Stefan Hajnoczi >>>> wrote: >>>> >>>>> 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. >>>> >>>> >>>> >>>> How would you capture the state of emulated hardware which might not >>>> be in the guest RAM? >>> >>> >>> Exactly the same way vmsave works today. It calls the device's save >>> functions which serialize state to file. >>> >>> The difference between today's vmsave and the fork(2) approach is that >>> QEMU does not need to wait for guest RAM to be written to file before >>> resuming the guest. >>> >>> Stefan >>> >> I have a worry about what glib says: >> >> "On Unix, the GLib mainloop is incompatible with fork(). Any program >> using the mainloop must either exec() or exit() from the child without >> returning to the mainloop. " > > This is fine, the child just writes out the memory pages and exits. > It never returns to the glib mainloop. > >> There is another way to do it: intercept the write in kvm.ko(or other >> kernel code). Since the key is intercept the memory change, we can do >> it in userspace in TCG mode, thus we can add the missing part in KVM >> mode. Another benefit of this way is: the used memory can be >> controlled. For example, with ioctl(), set a buffer of a fixed size >> which keeps the intercepted write data by kernel code, which can avoid >> frequently switch back to user space qemu code. when it is full always >> return back to userspace's qemu code, let qemu code save the data into >> disk. I haven't check the exactly behavior of Intel guest mode about >> how to handle page fault, so can't estimate the performance caused by >> switching of guest mode and root mode, but it should not be worse than >> fork(). > > The fork(2) approach is portable, covers both KVM and TCG, and doesn't > require kernel changes. A kvm.ko kernel change also won't be > supported on existing KVM hosts. These are big drawbacks and the > kernel approach would need to be significantly better than plain old > fork(2) to make it worthwhile. > > Stefan > I think advantage is memory usage is predictable, so memory usage peak can be avoided, by always save the changed pages first. fork() does not know which pages are changed. I am not sure if this would be a serious issue when server's memory is consumed much, for example, 24G host emulate 11G*2 guest to provide powerful virtual server. -- Best Regards Wenchao Xia