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