Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Markus Armbruster]

Thomas Huth <address@hidden> writes:

> On Tue, 26 May 2015 17:43:09 +0100
> Stefan Hajnoczi <address@hidden> wrote:
>
>> On Tue, May 26, 2015 at 3:36 PM, Daniel P. Berrange
>> <address@hidden> wrote:
>> > On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote:
>> >> Stefan Hajnoczi <address@hidden> 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 <address@hidden>
>> >> >> ---
>> >> >>  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.
>
> I'm certainly fine with both two approaches - as long as the -net vs.
> -netdev chaos finally goes away.
>
> However, there is one thing to consider: The "vlans" currently emulate
> some kind of hub hardware. If we do not support these with -netdev and
> finally remove -net one day, QEMU looses this feature, so that could be
> considered as a regression. Question is how useful this feature was
> beside connecting it to the dump device, and whether anybody really
> used it... for example, when running QEMU inside QEMU with nested
> virtualization, could the outer QEMU emulate a hub this way to connect
> the two contained virtual machines? OTOH, I think such behavior can
> also be reached by different means, so it should be ok to loose this
> feature, shouldn't it?

I wouldn't mind losing the "VLAN" / hub feature.  But if there's a
compelling use for it, I wouldn't mind keeping it, as long as it's out
of the way of users who don't need this niche feature.

So my goal isn't so much "get rid of hubs", it's "deprecate -net", and
"avoid dragging in a hub just for dumping packets".

I want us to deprecate -net, because:

* It forces a hub, which isn't what you want in the common case.

  Related: the default configuration gives you a hub, which is
  sub-optimal for most users.  Needs fixing.  The easiest way to
  configure networking also results in a hub.  Needs fixing, too.

* It's conceptually redundant, thanks to Stefan's hubport work.
  Unfortunately, it still dominates the user interface.

  -net boils down to a network device connected to a hubport, but our
  user interface doesn't let you do the boiling.  It does for -device's
  vlan parameter: you can always replace it by a netdev parameter
  referring to a suitable hubport created with -netdev.  I want the same
  for -net.

* -net nic adds another complication.  Like -serial, -drive if=ide and
  other similarly old options, it doesn't actually do anything, it
  merely sends a message to the board code, which may do with it
  whatever it wants.  Different boards to different things.  Separate
  rabit hole, better avoid it in this thread.

Thomas's patch brings half of what we have in -device to -netdev.
Unfortunately, it's the magic half: the vlan=N parameter to connect to
the hub with hubid=N, magically creating it if it doesn't exist already.
It doesn't bring the non-magic netdev=ID part to connect to an existing
hubport with id=ID.  That's the half I want if we can't get rid of hubs
outright.

-device needs the magic half for backward compatibility.  -netdev
doesn't.  An argument could be made to want it for consistency with
-device.  As far as I'm concerned: no thanks.

Thomas's patch does not address -net nic issues, and that's just fine.

Thomas's patch does not address "avoid dragging in a hub just for
dumping packets".  Dan sketched a way to do that.  It could make sense
even if we decide we want to keep hubs around for other, complicated
applications.