From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYk9m-0005u9-R5 for qemu-devel@nongnu.org; Tue, 22 Oct 2013 18:10:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYk9h-0001l2-SS for qemu-devel@nongnu.org; Tue, 22 Oct 2013 18:10:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYk9h-0001iA-Hq for qemu-devel@nongnu.org; Tue, 22 Oct 2013 18:10:25 -0400 Message-ID: <5266F7C4.6080700@redhat.com> Date: Tue, 22 Oct 2013 23:10:12 +0100 From: Eric Blake MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dbTg0OT7rWwVtv3007daghIcqn9Kkj3BR" Subject: Re: [Qemu-devel] About VM fork in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xinyang Ge , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dbTg0OT7rWwVtv3007daghIcqn9Kkj3BR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/22/2013 09:23 PM, Xinyang Ge wrote: > Dear QEMU developers, >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --dbTg0OT7rWwVtv3007daghIcqn9Kkj3BR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSZvfEAAoJEKeha0olJ0Nq3K0H/2cEApXV9iAqXhOuu61pk7GH PUQU6BJf9CaON4zwohj0EZZRAlLChtHlEqxY4WCuYPQjM/CPMvmrtkNKgmRTg2wf R5VUMbf3NVrFZNsvkAfmrUvnfwI9baZYpzrOC6+0KqD58g49CaX1YMAdMZch3CPm p/umk1WB0IGEaX9HVpVdEZFF3qw752eCkmWNtQakQZ7g0Lk3onimWNvQ7kRACLAP 0QrpPcfSURVHfeON2Izgvr+ov4EhAVbN29M4FZYqQcoI7NnQkDfMLWgp096fVMc6 n0682ZiG3gaJKGdKfRKFDA4WNAU+yKtxULMxwUgV7ol6jXAE3udDZUOSl+PoxeA= =ut4B -----END PGP SIGNATURE----- --dbTg0OT7rWwVtv3007daghIcqn9Kkj3BR--