From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yil-0000EI-CY for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:44:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9yih-00038I-0m for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:44:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yig-00036e-PH for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:44:42 -0400 Message-ID: <53CFD852.8090908@redhat.com> Date: Wed, 23 Jul 2014 09:44:18 -0600 From: Eric Blake MIME-Version: 1.0 References: <1406125538-27992-1-git-send-email-yanghy@cn.fujitsu.com> In-Reply-To: <1406125538-27992-1-git-send-email-yanghy@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LMH2pG77dTDhEQPOFP3uLN8r62XLdlRM1" Subject: Re: [Qemu-devel] [RFC PATCH 00/17] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yang Hongyang , qemu-devel@nongnu.org Cc: GuiJianfeng@cn.fujitsu.com, mrhines@linux.vnet.ibm.com, eddie.dong@intel.com, dgilbert@redhat.com, kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LMH2pG77dTDhEQPOFP3uLN8r62XLdlRM1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/23/2014 08:25 AM, Yang Hongyang wrote: > Virtual machine (VM) replication is a well known technique for > providing application-agnostic software-implemented hardware fault > tolerance "non-stop service". COLO is a high availability solution. > Both primary VM (PVM) and secondary VM (SVM) run in parallel. They > receive the same request from client, and generate response in parallel= > too. If the response packets from PVM and SVM are identical, they are > released immediately. Otherwise, a VM checkpoint (on demand) is > conducted. The idea is presented in Xen summit 2012, and 2013, > and academia paper in SOCC 2013. It's also presented in KVM forum > 2013: > http://www.linux-kvm.org/wiki/images/1/1d/Kvm-forum-2013-COLO.pdf > Please refer to above document for detailed information.=20 > Please also refer to previous posted RFC proposal: > http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg05567.html >=20 > The patchset is also hosted on github: > https://github.com/macrosheep/qemu/tree/colo_v0.1 >=20 > This patchset is RFC, implements the frame of colo, without > failover and nic/disk replication. But it is ready for demo > the COLO idea above QEMU-Kvm. > Steps using this patchset to get an overview of COLO: > 1. configure the source with --enable-colo option Code that has to be opt-in tends to bitrot, because people don't configure their build-bots to opt in. What sort of penalties does opting in cause to the code if colo is not used? I'd much rather make the default to compile colo unless configured --disable-colo. Are there any pre-req libraries required for it to work? That would be the only reason to make the default of on or off conditional, rather than defaulting to on. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --LMH2pG77dTDhEQPOFP3uLN8r62XLdlRM1 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTz9hSAAoJEKeha0olJ0Nq2DYH/3qTZL//2LTuwNmjYsGw3+/s 64ICh9wnptjyO7meHuqQdIReP0T26wH/KdwsDFNcAgeGmDI7d9UDqlmGpFzS6+t3 y1P0gSgn8oplYwGnWIW4zUN9IxG/cuTlfLrLdlCSDTz3aa81oNj+IZLdqCh1AmGw a8pl5H8/nQzici6AnOF2RDEya8iFBGbbOVNIyWHkUxebzYjSNH34plxYxHszuwzT S13t+tUF3n8Zxo0d9ZUCbXT2L4pGXUD/vml7BUDXub1Utj8gQApsRobV87Py8ZgF EyTWzMbmUEHHS24Pug4Yi0e0YocVndAGOwcz/oNnIsEDpYNvJ5tP99rinsAaN60= =+02r -----END PGP SIGNATURE----- --LMH2pG77dTDhEQPOFP3uLN8r62XLdlRM1--