Re: [Qemu-devel] [RFC]VM live snapshot proposal

[Huangpeng (Peter)]

> Yes, this is the tricky part.  To be honest, I think this is the reason no 
> one has
> submitted patches - it's a hard task and the win isn't that great (you can
> already migrate to file).
>
Yes, lots of places have to be considered. Though scenarios are limited, users 
like
library experiments may need to revert repeatedly to the same vm-state(memory 
state + disk state) .

The key-part is tracking and saving the consistent state right on snapshot 
time, 
kvm/qemu/vhost have already implement dirty-tracking and my proposal will add 
common save-old-page apis to save the consistent state. Is this way right or do 
you 
have other suggestions? 

> But back to the options:
> 
> If the host has enough free memory to fork QEMU, a small helper process can
> be used to save the copy-on-write memory snapshot (thanks to fork(2)
> semantics).  The hard part about the fork(2) approach is that QEMU isn't
> really designed to fork, so work is necessary to reach a quiescent state for 
> the
> child process.
> 
> If there is not enough memory to fork, then a synchronous approach to
> catching guest memory writes is needed.  I'm not sure if a good mechanism
> for that exists but the simplest would be mprotect(2) and a signal handler
> (which will make the guest run very slowly).
> 
> Stefan

In real production environment, memory over-commit or use as much memory as
possible may be the normal case, so the fork semantics cannot meet the needs.  

Is there any other proposals to implement vm-snapshot?

Thanks.