Re: [Qemu-devel] using -net dump with tap networking

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> Il 21/02/2013 15:41, Markus Armbruster ha scritto:
>> Trouble is the user interface is as confusing as ever.  Worse, in a way,
>> because we now have to explain how "vlan" and the hubport netdev relate.
>> 
>> Permit me a brief rant.  Have you read the manual page on -netdev and
>> -net recently?  Have you tried to explain setting up QEMU networking to
>> a neophyte?  Were you able to keep a straight face?  If yes, congrats,
>> you got a great future ahead of you.
>> 
>> We have so many ways to do the same thing, complicating our docs
>> enormously.  Just one of them makes sense for almost all uses, but I
>> doubt mortal users could guess which one just from the docs.
>> 
>> Can we do for the docs what Stefan did for the code, i.e. get "vlans"
>> out of the way?
>> 
>> Specifically, what's missing to let us deprecate -net completely?
>
> Less important: the fact that "-net dump" is quite useful and requires
> vlans.

Let me rephrase: dumping network traffic is quite useful, and our
current way to do that from within QEMU requires "vlans".

The "dump" vlan client is neither a net frontend nor a net backend, it's
a passive listener.  Could also be viewed as special case of a filter
that happens not to change anything.

If it's the only useful listener or filter, we could just special-case
it and be done.

If not, we need a way to attach listeners to the 1:1 netdev connections,
or turn it in a chain with filters as interior nodes.

>        ("-net socket" has some usecases too: "-net bridge" helps placing
> a VM's network on a bridge, but adding a bridge still requires root
> privileges).

"-netdev socket" and "-netdev bridge" don't cut it?

> More important: the fact that qdev and -device really only works for ISA
> and PCI devices.  Boards whose NICs are sysbus devices can only add
> networking with "-net nic".

To be more precise: -device currently works only for devices on
pluggable buses.

Anything you could plug on a physical machine should be on a pluggable
bus (whether we implemented plugging is another question).

Anything you couldn't plug on a physical machine must be soldered onto
the board.  Boards often come in a few flavours with different onboard
devices.  Virtual boards tend to sprout more flavours.  Because of that,
thinking in board options you can combine is often more convenient than
having a finite number of board variants.

QOM will hopefully enable us to stitch devices together without the need
for buses.  But we're not there, yet.  When we are, we still have to
bridge the gap from "interface suitable for building machines from
components" to "nice command line interface for customizing machines".

So, I quite agree that we need a way to configure board options.  Our
current way to do that for NICs is multiplexed into -net as "-net nic".

"-net nic" is quite unlike the other -net: it doesn't create a vlan
client, it asks the board to create a NIC device.  Parameter "model"
lets you ask for a specific one.

Boards can do what they want with these requests.  Some boards don't
support NICs and simply ignore these requests (generic code attempts to
detect that and warn).  Others treat models they don't know as fatal
error.  Some boards create exactly the NICs you asked for.  Others
create exactly their onboard NICs, whether you asked for them or not
(asking is merely a way to supply configuration parameters).

Most (all?) boards can tell you what models they support (-net
nic,model=help), but some lie, e.g. PCs neglect to mention model
ne2k_isa.

Boards supporting PCI generally recognize a few common PCI NIC models.
But you're better off using -device there, because it gives you access
to all device models and options at no extra charge.

"Well, here's another nice mess you've gotten me into, Stanley!"


TL;DR: I quite agree that we can't just throw away -net without a
replacement.  I just think it's a mess, and should be replaced.