From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQULg-0007Tj-8M for qemu-devel@nongnu.org; Wed, 25 Feb 2015 00:17:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQULb-0005qm-9M for qemu-devel@nongnu.org; Wed, 25 Feb 2015 00:17:28 -0500 Received: from [59.151.112.132] (port=39526 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQULa-0005pN-If for qemu-devel@nongnu.org; Wed, 25 Feb 2015 00:17:23 -0500 Message-ID: <54ED5AE1.7010704@cn.fujitsu.com> Date: Wed, 25 Feb 2015 13:17:21 +0800 From: Gao feng MIME-Version: 1.0 References: <1423711034-5340-1-git-send-email-zhang.zhanghailiang@huawei.com> <20150216131100.GC2299@work-vm> In-Reply-To: <20150216131100.GC2299@work-vm> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v3 00/27] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , zhanghailiang Cc: yunhong.jiang@intel.com, eddie.dong@intel.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com, stefanha@redhat.com, pbonzini@redhat.com On 02/16/2015 09:11 PM, Dr. David Alan Gilbert wrote: > * zhanghailiang (zhang.zhanghailiang@huawei.com) wrote: >> > This is the 3th version of COLO, it is only COLO frame part, include: = VM checkpoint, >> > failover, proxy API, block replication API, not include block replicat= ion. >> > The block part has been sent by wencongyang: >> > '[RFC PATCH 00/14] Block replication for continuous checkpoints' >> >=20 >> > You can get the integrated qemu colo patches from github: >> > https://github.com/coloft/qemu/commits/colo-v1.0 >> >=20 >> > Compared with the previous version, we have realized all parts of COLO= frame,=20 >> > and it is works now. >> >=20 >> > The main change since last version is, we use colo proxy mode instead = of >> > colo agent, they are all used for network packets compare, but proxy i= s more >> > efficient, it is based on netfilter. >> > Another modification is we implement new block replication scheme,=20 >> > you can get more info from wencongyang's block patch series=20 >> >=20 >> > If you don't know about COLO, please refer to below link for detailed= =20 >> > information. >> >=20 >> > The idea is presented in Xen summit 2012, and 2013, >> > and academia paper in SOCC 2013. It's also presented in KVM forum in 2= 013: >> > http://www.linux-kvm.org/wiki/images/1/1d/Kvm-forum-2013-COLO.pdf >> >=20 >> > Previous posted RFC proposal: >> > http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg05567.html >> > http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg04459.html >> >=20 >> > The below is the detail about test COLO, you can also get this info >> > from http://wiki.qemu.org/Features/COLO. >> > * Hardware requirements >> > There is at least one directly connected nic to forward the network re= quests >> > from client to secondary VM. The directly connected nic must not be us= ed by >> > any other purpose. >> >=20 >> > * Network link topology >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dnormal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> > +--------+ >> > |client | >> > master +----+---+ slave >> > -------------------------+ | + ------------------= -------+ >> > PVM | + | = | >> > +-------+ +----[eth0]-----[switch]-----[eth0]---------+ = | >> > |guest | +---+-+ | | +---+-+ = | >> > | [tap0]--+ br0 | | | | br0 | = | >> > | | +-----+ [eth1]-----[forward]----[eth1]--+ +-----+ = SVM | >> > +-------+ | | | +-= ------+| >> > | | | +-----+ | = guest || >> > [eth2]---[checkpoint]---[eth2] +--+br1 |-[tap= 0] || >> > | | +-----+ | = || >> > | | +-= ------+| >> > -------------------------+ +-------------------= -------+ >> > e.g. >> > master: >> > br0: 192.168.0.33 >> > eth1: 192.168.1.33 >> > eth2: 192.168.2.33 >> >=20 >> > slave: >> > br0: 192.168.0.88 >> > br1: no ip address >> > eth1: 192.168.1.88 >> > eth2: 192.168.2.88 >> > (Actually, you can also use eth0 as checkpoint channel) >> > Note: in normal, SVM will always be linked to br1 like above until >> > failover. > Why does eth1 need IP addresses?=20 Yes, eth1 shouldn't have IP address. > Isn't the traffic on eth1 just a copy of the > traffic on eth0 for the proxy modules to compare/forward? you are right. > Wouldn't any ARP traffic or the like generated from having IPs on those > interfaces confuse the comparison process? Yes, the arp packet sending from slaver eth1 may confuse the proxy. > (Similarly for the bridges, is it best to turn off STP and the like > to stop the bridges adding extra packets on eth1/eth0 ?) >=20 I haven't checked if enable STP will cause some problem, but proxy only handle the packets witch has related netfilter conntrack. in my test, proxy runs well when STP is enabled. Thanks=EF=BC=8C Gao