qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v3 00/27] COarse-grain LOck-stepping(COLO) V


From: Gao feng
Subject: Re: [Qemu-devel] [PATCH RFC v3 00/27] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service
Date: Wed, 25 Feb 2015 13:17:21 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]