a KVM VMs presented to be a qemu-kvm process.
In some cases,if we want to clone VMs,why not to use fork?
As I see,There are two adveantages at least:
- sub VM will share memory with copy-on-write,reduce the memory consumption.
- clone VM on the fly with the copy-on-write
Of course,there some problems to solve,Like
- design a disk copy-on-write to share the main VM image file.
- redirect sub VMs IO.
If you are running your VM without kernel-level virtualization (in other words, you’re using QEMU emulation) then this would probably Just Work, apart from all the problems with the duplicated I/O you refer to. You could probably work around the disk problems by running your VMs in ‘-snapshot’ mode. Similarly, if your VMs are headless (no video emulation) then that would be OK. The only remaining problem would be the duplicated networking.
If you’re expecting this to work with real KVM VMs then I think you’re going to be unlucky.
Even if you could do it, I’m not sure you’d get the advantages you imagine. If you start two VMs independently (or any other application), then they will already have shared memory for any files they open (obviously they could only really share read-only files). That includes read-only disk mounts, the KVM/QEMU executables and libraries themselves, and whatever else they need. The only additional sharing you would get in your scheme is the data tables, and then only the ones in use before your fork, and that sharing would be relatively short-lived because any update to that data will cause a copy-on-write. (Actually, this might be a win in QEMU of a foreign architecture where there are large quantities of cached JIT-generated executable code, but I don’t think that’s what you were referring to.)