From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rs2bH-0003FX-23 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:33:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rs2bF-0004lO-Jb for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:33:35 -0500 Received: from [222.73.24.84] (port=56523 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rs2bE-0004l8-Lx for qemu-devel@nongnu.org; Mon, 30 Jan 2012 20:33:33 -0500 Message-ID: <4F274578.1020505@cn.fujitsu.com> Date: Tue, 31 Jan 2012 09:35:52 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F17907E.4070302@cn.fujitsu.com> <4F184607.10509@redhat.com> <4F262D44.9040109@cn.fujitsu.com> <4F26D5AB.9040801@redhat.com> In-Reply-To: <4F26D5AB.9040801@redhat.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Jan Kiszka , qemu-devel , Luiz Capitulino , HATAYAMA Daisuke , Dave Anderson , Jun Koi At 01/31/2012 01:38 AM, Eric Blake Wrote: > On 01/29/2012 10:40 PM, Wen Congyang wrote: >>>> Yes, it may tak a lot of time. But we dump a guest memory when the guest >>>> panics, and there is no need to continue to run the guest. >>> >>> Would it be possible to have both a dump from a certain point in time >>> and still allow the guest to run unpaused? >>> >>> I'm thinking something along the lines of pausing the guest, setting up >>> control structures, then calling fork(). The parent can then unpause, >>> and use the control structures to communicate the memory state from the >>> child back out the monitor. Meanwhile, the guest has a copy-on-write >>> clone of the entire memory state, so as long as the control structures >>> guarantee that the child will not accept any monitor commands and not >>> resume the guest, then the child process can be used to stream the >>> memory contents as they were at the time of the dump command back over >>> the control structure back to the parent process. I will admit, >>> however, that following the fork(), you would be limited to >>> async-signal-safe functions, so it may be a rather difficult task to design. >>> >> >> I do not understand this section. Do you say the reason of allowing the guest >> to run unpaused? Or do you say the way to do it? > > Among other reasons for supporting a guest that runs in parallel with a > memory dump, I'm envisioning a thin-provisioning setup. Right now, you > have to get a common off-line base disk image state, then each cloned > guest has to boot from scratch as a delta from that base state. But it > would be a lot faster if you could get a common on-line VM state, and > start cloned guests from the same memory state as the baseline. Taking > it further, I can envision a forensic-style application, that runs > what-if scenarios, by running two similar guests side by side and seeing > what happens when only one of the two guests has a particular tweak > made. Or suppose you have a production server, and want to apply a > patch, but want to make sure the patch will work before committing to it > - the obvious way is to apply the patch to a temporary cloned VM. But > because it is a production server, you can't afford to wait for a long > downtime with the guest paused just to capture the machine state for > cloning a temporary VM for testing out the patch. > > Basically, in all of these scenarios, my idea is that it should be easy > (well, at least easier than it currently is), to create a new guest > based on the memory state of an existing guest, all without impacting > the existing guest. And to do that, it would be nice to be able to > reliably dump the state of memory of a guest at a given point of time, > all while continuing to let the original guest run past that point in time. > > But whether this has to be done right away, or whether it even fits in > with your 'dump' command vs. needing a command of its own, I don't know. > Thanks for your explantion. I know what you want, and I think it needs a command of its own. Because the 'dump' command only provides memory, and it does not include device's state, CPU's state, and so on. If the guest uses host devices, and i think it should not be cloned. If you want to get all the state of the guest, you may need a command like 'mirgate' command. Thanks Wen Congyang