From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjWua-0004Uk-5k for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:20:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjWuT-0001uB-9T for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:19:56 -0400 Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]:61115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjWuT-0001tk-1K for qemu-devel@nongnu.org; Wed, 29 Oct 2014 13:19:49 -0400 Received: by mail-la0-f43.google.com with SMTP id ge10so2948877lab.2 for ; Wed, 29 Oct 2014 10:19:47 -0700 (PDT) Date: Wed, 29 Oct 2014 17:19:43 +0000 From: Stefan Hajnoczi Message-ID: <20141029171943.GK19774@stefanha-thinkpad.redhat.com> References: <1411464235-5653-1-git-send-email-yanghy@cn.fujitsu.com> <54508EF5.8000908@cn.fujitsu.com> <20141029093457.GB2310@work-vm> <5450B938.503@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dxRQSzdsN/lOP445" Content-Disposition: inline In-Reply-To: <5450B938.503@cn.fujitsu.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 00/23] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Gui Jianfeng , Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , "Michael R. Hines" , qemu-devel@nongnu.org, Paolo Bonzini , Walid Nouri , Yang Hongyang --dxRQSzdsN/lOP445 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2014 at 05:54:00PM +0800, Wen Congyang wrote: > On 10/29/2014 05:34 PM, Dr. David Alan Gilbert wrote: > > * Wen Congyang (wency@cn.fujitsu.com) wrote: > >=20 > > > >=20 > >> Hi all: > >> > >> I will start to implement disk replication. Before doing this, I think= we should decide > >> how to implement it. > >> > >> I have two ideas about it: > >> 1. implement it in qemu > >> Advantage: very easy, and don't take too much time > >> Disadvantage: the virtio disk with vhost is not supported, because = the disk I/O > >> operations are not handled in qemu. > >> > >> 2. update drbd and make it support colo > >> Advantage: we can use it for both KVM and XEN. > >> Disadvantage: The implementation may be complex, and need too much = time to > >> implement it.(I don't read the drbd's codes, and can't estimat= e the cost) > >> > >> I think we can use 1 to implement it first. > >> If you have some other idea, please let me know. > >=20 > > For the COLO disk replication; are you talking here about 'local storag= e' > > and treating it as 'internal state' or 'external state' (as described i= n the > > first half of 4.4 in the original COLO paper)? >=20 > I don't know what is 'internal state' or 'external state'. > What I want to implement is: > 1. forward primary vm's write operation(start sector, size, content) to s= econdary vm > 2. Cache the primary vm's write operation in secondary vm's qemu > 3. cache the secondary vm's write operation in secondary vm's qemu > 4. flush primary vm's write operation, and drop secondary vm's write oper= ation after a > checkpoint > 5. drop primary vm's write operation and flush secondary vm's write opera= tion when doing > failover. This is more complicated than it sounds. I suggest writing a prototype in QEMU and sending RFC patches to the mailing list. After the error scenarios and problems have been fully thought through, then it will be clearer whether to implement it in QEMU or the kernel. Stefan --dxRQSzdsN/lOP445 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUUSGvAAoJEJykq7OBq3PI8xQIAI99g17+L5Q8mEcww+YDTJRn V+/sgQzvQNMoosohY27FGfw6/7DBMalLRHW6zYuM0aF2KSEbVWKgG80OOCUEQPN0 0wUUMPI9UaqPsN+I31C5bJEOm+QpWSO5O+ET2ThsR5VkDF3Sq8bXl6NXCIP7Pbmo QNx7AqWKU3TGnsodDIl9RS7zLEE19z1GDXwYxikLJ1mACti0e5NwVbx4t0iuS4xt 5yCIFbphi5V52a8W0b/BUmRYiCf311iw42K/PQ0j3VyKm05AJTrIzoKmVG1eF3Es kB/RKPcTnHoX2pNYKPiborl+lxkvNNczGCdEWgK9M+5b84EsZXnUEohIkPlHIiw= =/72W -----END PGP SIGNATURE----- --dxRQSzdsN/lOP445--