Re: [Qemu-devel] [POC] colo-proxy in qemu

[Li Zhijian <lizhijian@cn.fujitsu.com>]

CC Wen Congyang

On 07/20/2015 06:32 PM, Stefan Hajnoczi wrote:
> On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
>> We are planning to implement colo-proxy in qemu to cache and compare packets.
> I thought there is a kernel module to do that?
>
> Why does the proxy need to be part of the QEMU process?  -netdev socket
> or host network stack features allow you to process packets in a
> separate process.
yes, it used to be a kernel module.
we plan to re-implement a QEMU space colo-proxy by the following reasons:
1. colo-proxy in kernel was based on netfilter, it was
impletmented by add a new nf_ct_ext_id, but this will
touch the existed kernel code and we must re-build the kernel before
we install the colo-proxy modules. For this reason, less people
is like to test colo-proxy and it become harder to post to kenel
2. COLO is the only scene of colo-proxy in kernel
3. colo-proxy in kernel only works on the case where packet will deliver to
kernel tcp/ip stack.

COLO project is mainly including 3 components, COLO-Frame COLO-Block and 
COLO-Proxy.
The first tow components is being post to QEMU, if we integrate proxy 
into QEMU,
it will become convenienter to manage the whole COLO project.
further more, COLO will become easier to configure without depending on 
kernel


> Without details on what the proxy does it's hard to discuss this.  What
> happens in the non-TCP case?  What happens in the TCP case?
more details will be post soon


> Does the proxy need to perform privileged operations, create sockets,
> open files, etc?
IMO, we just need to create a new socket like the migration socket to
forward packet between PVM and SVM.

Best regards.
Li Zhijian

> The slirp code is not actively developed or used much in production.  It
> might be a good idea to audit the code for bugs if you want to use it.
>
> Stefan