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. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature