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
