From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZvHf-0001MC-RC for qemu-devel@nongnu.org; Sat, 26 Oct 2013 00:15:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZvHa-0002Rz-TD for qemu-devel@nongnu.org; Sat, 26 Oct 2013 00:15:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZvHa-0002Rv-Fp for qemu-devel@nongnu.org; Sat, 26 Oct 2013 00:15:26 -0400 Message-ID: <526B41D0.90506@redhat.com> Date: Sat, 26 Oct 2013 05:15:12 +0100 From: Eric Blake MIME-Version: 1.0 References: <5266F7C4.6080700@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8sNK6FbPg90O6mE8U8LpekLoIJtwpmJXW" Subject: Re: [Qemu-devel] About VM fork in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xinyang Ge Cc: Hayawardh Vijayakumar , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8sNK6FbPg90O6mE8U8LpekLoIJtwpmJXW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/23/2013 03:36 PM, Xinyang Ge wrote: >> Live cloning is a disaster waiting to happen if not done in a very >> carefully controlled environment (I could maybe see it useful across t= wo >> 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 gue= st >> locations. With offline disk images, the set of information to scrub = is >> a bit easier, and in fact, 'virt-sysprep' from the libguestfs tools ca= n >> 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 i= n >> parallel, or is it sufficient to serialize the running of one variatio= n >> followed by the other variation? >=20 > It's better to have them run in parallel since our project doesn't > have any network stuff. Good, then it sounds like you are being careful about avoiding the worst aspect of live cloning (as long as two guests are never visible to the same network, then you aren't exposing security risks over that network).= > However, running each variation sequentially > is also sufficient for us. What we are concerned the most is whether > we can get a snapshot in milliseconds because we don't really need to > save the memory state to disk for future reversion. Could you let me > know if it's possible for qemu or qemu-kvm with minor changes? External snapshots (via the blockdev-snapshot-sync QMP command) can be taken in a matter of milliseconds if you only care about disk state. Furthermore, if you want to take a snapshot of both memory and disk state, such that the clone can be resumed from the same time, you can do that with a guest downtime that only lasts as long as the blockdev-snapshot-sync, by first doing a migrate to file then doing the disk snapshot when the VM pauses at the end of migration. Resuming the original guest is fast; resuming from the migration file is a bit longer, but it is still the fastest way possible to resume from a memory+disk snapshot. If you need anything faster, then yes, you would have to write patches to qemu to attempt cloning via fork() that makes sure to modify the active disk in use by the fork child so as not to interfere with the fork parent. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --8sNK6FbPg90O6mE8U8LpekLoIJtwpmJXW 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/ iQEcBAEBCAAGBQJSa0HQAAoJEKeha0olJ0NqUTQH/j3hbqgtulBJHtuFOf62KtBV cD7aSMoHvRjtHeakJrRrDUUmiUMlWTsX9sUSLWIxalNcOiZe8jBqbafaRvvasNrN uQMvn2m3kY/2ob5LQ29qNtiPNSTLCauV7ezdCk7lOx8Zran7rg/wJYfI+8SVj9q9 JBPPkTVUSvy+ldDCKaEw4mgO/DUSUHNe640bz+8p293NOo6ed/4YkhV3+pjKFl1+ oRPrZ6YMikXPscXVkzOLNCufA+LCTAtgavizjXby3Snt1a5rHqqjW0ekkr1jH/5w 1baLeO+reIGdNmeh8+wcW2pqJ1mHiYhRGBUVAm8W77yzOHDEykMm8voPKoK2FdE= =aJrl -----END PGP SIGNATURE----- --8sNK6FbPg90O6mE8U8LpekLoIJtwpmJXW--