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