Re: [Qemu-devel] [PATCH RFC v3 00/27] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service

[Gao feng]

On 02/16/2015 09:11 PM, Dr. David Alan Gilbert wrote:
> * zhanghailiang (address@hidden) 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 replication.
>> > The block part has been sent by wencongyang:
>> > '[RFC PATCH 00/14] Block replication for continuous checkpoints'
>> > 
>> > You can get the integrated qemu colo patches from github:
>> > https://github.com/coloft/qemu/commits/colo-v1.0
>> > 
>> > Compared with the previous version, we have realized all parts of COLO 
>> > frame, 
>> > and it is works now.
>> > 
>> > 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 is 
>> > more
>> > efficient, it is based on netfilter.
>> > Another modification is we implement new block replication scheme, 
>> > you can get more info from wencongyang's block patch series 
>> > 
>> > If you don't know about COLO, please refer to below link for detailed 
>> > information.
>> > 
>> > The idea is presented in Xen summit 2012, and 2013,
>> > and academia paper in SOCC 2013. It's also presented in KVM forum in 2013:
>> > http://www.linux-kvm.org/wiki/images/1/1d/Kvm-forum-2013-COLO.pdf
>> > 
>> > 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
>> > 
>> > 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 
>> > requests
>> > from client to secondary VM. The directly connected nic must not be used by
>> > any other purpose.
>> > 
>> > * Network link topology
>> > =================================normal 
>> > ======================================
>> >                                 +--------+
>> >                                 |client  |
>> >    master                       +----+---+                    slave
>> > -------------------------+           |            + 
>> > -------------------------+
>> >    PVM                   |           +            |                        
>> >   |
>> > +-------+         +----[eth0]-----[switch]-----[eth0]---------+            
>> >   |
>> > |guest  |     +---+-+    |                        |       +---+-+          
>> >   |
>> > |     [tap0]--+ br0 |    |                        |       | br0 |          
>> >   |
>> > |       |     +-----+  [eth1]-----[forward]----[eth1]--+  +-----+      SVM 
>> >   |
>> > +-------+                |                        |    |            
>> > +-------+|
>> >                          |                        |    |  +-----+   | 
>> > guest ||
>> >                        [eth2]---[checkpoint]---[eth2]  +--+br1  |-[tap0]   
>> >  ||
>> >                          |                        |       +-----+   |      
>> >  ||
>> >                          |                        |                 
>> > +-------+|
>> > -------------------------+                        
>> > +--------------------------+
>> > e.g.
>> > master:
>> > br0: 192.168.0.33
>> > eth1: 192.168.1.33
>> > eth2: 192.168.2.33
>> > 
>> > 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? 

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 ?)
> 

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，
Gao