On Tue, May 26, 2015 at 3:36 PM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote: >> Stefan Hajnoczi <stefa...@redhat.com> writes: >> >> > On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote: >> >> So far, it is not possible to use the network dump interface >> >> with the "-netdev" option yet, it only works with the legacy >> >> "-net" option. To be able to use it with "-netdev", too, this >> >> patch now enables the "vlan" packet distribution for the >> >> "-netdev" option, too, so that you can now dump network packets >> >> like this: >> >> >> >> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \ >> >> -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \ >> >> -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat >> >> >> >> Signed-off-by: Thomas Huth <th...@redhat.com> >> >> --- >> >> net/net.c | 3 +++ >> >> qapi-schema.json | 1 + >> >> 2 files changed, 4 insertions(+) >> >> >> >> [Note: I'm quite new to this area of the code, please review carefully >> >> whether this approach makes sense or whether it should be done >> >> differently] >> > >> > We thought the QEMU "vlan" concept would be dropped completely in the >> > future, so it was never added to -netdev. No patches to do that have >> > been posted over the years, so I think it was more of a conceptual goal >> > than a concrete requirement. >> >> Well, patches to do that first need to replace the VLAN-only dump >> feature. >> >> To fully deprecate -net, we also have to replace -net nic for >> configuring onboard NICs. >> >> Prior discussion: >> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html >> >> We haven't really tried either. >> >> Thomas's patch declares defeat on VLANs: it ports them to -netdev, >> perpetuating the concept. >> >> > I'm okay with merging this but will leave some time for discussion >> > before merging the patch. >> > >> > "Speak now or forever hold your peace" >> >> Sure we're ready to give up without having tried? > > Seems to me that we'd be better off taking the -netdev arg and > adding a new parameter 'dump=filename' that can be used with any > netdev backend. eg with tap > > -netdev tap,id=foo,fd=3,dump=/somefile,dumplen=1024 > > The use of a dedicated 'dump' network backend always appear rather > strange as a conceptual approach, and I don't think we should > propagate its use into -netdev
I'm happy with this approach too. Stefan
