> 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.
��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
