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

[Wen Congyang]

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