Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

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   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]