Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu

[Jamie Lokier <jamie@shareable.org>]

Avi Kivity wrote:
> On 11/07/2009 12:44 PM, Jamie Lokier wrote:
> >Aiee - what's the plan?  Can a running KVM be forked, as in into two
> >separate processes to run the forked guests in parallel, or not?
> 
> kvm fds do not support fork().  Nothing prevents you from stopping the 
> guest, reading guest state, fork()ing, and creating a new VM in the 
> child with the same state, then restarting both instances.
> 
> qemu in general cannot be forked; the two instances would trample on 
> each others disk images, host network connections (i.e. vnc, X, the 
> monitor), guest network connections, etc.

Oh, I understand that qemu forking is fraught.  It would need to fork
at just the right moment and recreate all sorts of things.

And I'm not surprised that the kvm fd does not fork.  Why should it?
fds refer to device instances, and fork does not generally create new
instances.

What I'd like to know is, if all of QEMU's state is appropriately
recreated in the child instance, and KVM's device is reopened with a
copy of the kvm state (by using the recently introduced ioctls to get
and set it), will it fork the _guest RAM_ mapped into KVM in the way
that fork does?

Or is it necessary to copy all the guest RAM from original instance
into the new ones, so that there must be multiple copies of all the
guest RAM pages, even if they are the same?

What I have in mind is a "test state server", which is a KVM instance
halted in a state where loadvm has loaded up all of guest memory in a
state where the guest is ready to do something.

Incoming requests cause that server to fork off and start all the
device emulations, open network connections, create -snapshot qcow2
temporary fork files, etc., so the forked child is a running VM, doing
whatever it was poised to do, with no permanent effect.

(Naturally the guest would have to be in a usefully prepared state,
probably it's just about to run a network config script to get it's
per-instance settings and then fetch a test script to run.)

Basically, will KVM (the kernel bits) work using guest RAM which is
shared with other guest instances and a non-guest instance (the parent
process which hasn't yet started KVM) in that way?

Will KVM (the kernel bits) also work the other way, where it is paused
and all the devices closed (as if we're doing savevm and shutting
down), but instead of saving and unmapping guest memory, only the
device state is savevm'd, that's used to put it into the halted state
described above, from which it's able to reload device state and
continue?

In a nutshell, does KVM mind the guest's memory pages (including
device memory like framebuffers) being COW-shared in all the ways that
fork() can cause?

I know it's an arcane question, so thanks a lot if you answer! :-)
-- Jamie