Re: [Qemu-devel] About VM fork in QEMU

[Eric Blake]

On 10/22/2013 09:23 PM, Xinyang Ge wrote:
> Dear QEMU developers,
> 
> I am a Ph.D. student in Penn State. And we are currently working on a
> project that needs to fork multiple instances of a same VM instance
> with exactly same state (e.g., memory layout, registers, etc.) in a
> very efficient way. Snapshot is too heavy for us because it needs to
> dump the memory state to the filesystem so that reverting is possible
> sometime later. Our project does not need to revert a VM to a previous
> snapshot but lively clone (or fork) multiple instances and make them
> run at the same time. Do you happen to know if it's possible to do
> this? What we are envisioning is copy-on-write would happen both on
> disks (e.g., qcow2) and memory state (e.g., physical pages).

Live cloning is a disaster waiting to happen if not done in a very
carefully controlled environment (I could maybe see it useful across two
private networks for forensic analysis or running "what-if" scenarios,
but never for provisioning enterprise-quality public-facing servers).
Remember, if you ever expose both forks of a live clone to the same
network at the same time, you have a security vulnerability if you did
not manage to scrube the random pool of the two guests to be different,
where the crypto behavior of the second guest can be guessed by
observing the behavior of the first.  But scrubbing memory correctly
requires knowing EXACTLY where in memory the random pool is stored,
which is highly guest-dependent, and may be spread across multiple guest
locations.  With offline disk images, the set of information to scrub is
a bit easier, and in fact, 'virt-sysprep' from the libguestfs tools can
do it for a number of guests, but virt-sysprep (rightfully) refuses to
try to scrub a live image.  Do your forked guests really have to run in
parallel, or is it sufficient to serialize the running of one variation
followed by the other variation?

As far as I know, the only way to run two guests that diverge from the
same live state is to take a snapshot and then run two qemu instances
that both point to that common state as their starting point, and I
would personally never attempt it in parallel.  Meanwhile, although you
complained that snapshots are too heavyweight, it's really the only way
I know to even begin to attempt live cloning with current qemu.  Of
course, being open source, you're welcome to submit a patch to add
features to qemu to do a faster live clone.  But be prepared for an
uphill battle if you cannot prove that such a patch does not introduce
security implications running improperly scrubbed forks in parallel.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature