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

[Eric Blake]

On 10/23/2013 03:36 PM, Xinyang Ge wrote:
>> 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?
> 
> It's better to have them run in parallel since our project doesn't
> have any network stuff.

Good, then it sounds like you are being careful about avoiding the worst
aspect of live cloning (as long as two guests are never visible to the
same network, then you aren't exposing security risks over that network).

> However, running each variation sequentially
> is also sufficient for us. What we are concerned the most is whether
> we can get a snapshot in milliseconds because we don't really need to
> save the memory state to disk for future reversion. Could you let me
> know if it's possible for qemu or qemu-kvm with minor changes?

External snapshots (via the blockdev-snapshot-sync QMP command) can be
taken in a matter of milliseconds if you only care about disk state.
Furthermore, if you want to take a snapshot of both memory and disk
state, such that the clone can be resumed from the same time, you can do
that with a guest downtime that only lasts as long as the
blockdev-snapshot-sync, by first doing a migrate to file then doing the
disk snapshot when the VM pauses at the end of migration.  Resuming the
original guest is fast; resuming from the migration file is a bit
longer, but it is still the fastest way possible to resume from a
memory+disk snapshot.  If you need anything faster, then yes, you would
have to write patches to qemu to attempt cloning via fork() that makes
sure to modify the active disk in use by the fork child so as not to
interfere with the fork parent.

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

signature.asc
Description: OpenPGP digital signature