qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devic


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices
Date: Fri, 16 Jul 2010 17:45:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Anthony Liguori wrote:
> On 07/15/2010 03:22 PM, Miguel Di Ciurcio Filho wrote:
>> Hello,
>>
>> This is a prototype suggestion. I mostly copied and pasted the code from
>> net/dump.c into net.c and made some adjustments. There is no command line
>> parsing involved yet, just the internals and small changes in
>> net/tap.c and
>> net/slirp.c do make the thing work.
>>
>> In my tests, using tap as backend, e1000 as a guest device and running
>> iperf from
>> guest to host, the overhead of dumping the traffic caused a loss of
>> around 30%
>> of performance.
>>
>> I opened the dumped files in wireshark and they looked fine. When
>> using slirp
>> all requests were dumped fine too.
>>    
> 
> A less invasive way to do this would be to chain netdev devices.
> 
> Basically:
> 
> -netdev tap,fd=X,id=foo
> -netdev dump,file=foo.pcap,netdev=foo,id=bar
> -net nic,model=virtio,netdev=bar
> 
> I think this has some clear advantages to this architecturally.  From a
> user perspective, the only loss is that you have to add the dump device
> at startup (you can still enable/disable capture dynamically).

At least I tend to forget this, and then you already have a VM running
without that chain. And it looks like dynamic reconfiguration of the
backend (netdev_del/add) implies hot-removing/adding the frontend as
well. So this is also no option if the guest does not support that. A
bit unhandy.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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