Re: [Qemu-trivial] [Qemu-devel] [PATCH] net: Mark the 'hubport' netdev as deprecated

[Thomas Huth]

On 20.09.2017 13:07, Paolo Bonzini wrote:
> On 20/09/2017 09:45, Thomas Huth wrote:
>> On 24.05.2017 10:04, Thomas Huth wrote:
>>> The 'hubport' netdev is closely tied to the 'vlan' concept which
>>> has been marked as deprecated in commit a2dbe1356faff3cb6 already.
>>> Thus we should also mark the hubport netdevs as deprecated to make
>>> the remaining users aware that they should not use this anymore.
>>>
>>> Signed-off-by: Thomas Huth <address@hidden>
> 
> What is the replacement for VLANs?
> 
> The point of hub/hubport was to implement this without needing
> special-casing of VLANs everywhere in the net/ directory.  VLANs remain
> messy in terms of command-line expression for -net, but that's where the
> problems end.

The QEMU "VLAN"s are a complete PITA for the users, they are causing
confusion (e.g. https://bugs.launchpad.net/qemu/+bug/658904) and
mis-configurations (see e.g.
http://lists.gnu.org/archive/html/qemu-discuss/2017-08/msg00031.html).
So I hope you agree that we should get rid of this "vlan" stuff in QEMU
(no matter whether we continue to provide some kind of "hub" or "switch"
instead or completely remove it).

> In fact, while there are some uses of VLANs that have been replaced by
> filters, VLANs are still needed to place 2 NICs to be on the same guest
> network without using a host bridge.  This should be a supported use
> case for e.g. L2TP backends, and it can be important for users that
> don't have the ability to configure a host bridge.

I don't think that anybody really wants to connect two NICs of one
machine to a *hub* - all the network traffic of one NIC will go to the
other, too! That might only make sense if you want to do some basic
network driver tests in your guest, but for every normal OS, this is
nonsense. You normally are also not doing this with real hardware (note
that we're talking about hubs, not switches!).

> Rather than deprecating hubport, we need a mechanism to define a hubport
> for the back-end side.  For example:
> 
>    -netdev l2tp,...,id=l2tp-backend
>    -netdev hubport,hubid=0,netdev=l2tp-backend,id=l2tp-hub
>    -netdev hubport,hubid=0,id=nic0 -device virtio-net-pci,netdev=nic0
>    -netdev hubport,hubid=0,id=nic1 -device virtio-net-pci,netdev=nic1
> 
> This would normalize the topology
> 
>    NIC      NIC      L2TP
>     |        |        |
>    hubport  hubport   |
>     |        |        |
>     '--------'--------'-------- hub
> 
> to
> 
>    NIC      NIC      L2TP
>     |        |        |
>    hubport  hubport  hubport
>     |        |        |
>     '--------'--------'-------- hub
> 
> and would let us drop vlan from the command-line options.  Even
> immediately in 2.11.

While that looks at least way more logical than the "vlan" parameter, I
really doubt that we need a *hub* within QEMU. Emulating a switch might
make at least a little bit more sense ... but still, do we really need
this? Do you have any real world example where somebody is using QEMU
for a configuration like this?

 Thomas


PS: Or are you just afraid that we might finally get rid of the short
"-net nic -net tap" syntax, which is way easier to type than its -netdev
equivalent? Well, I'd say that's a different topic, and we should come
up with a new convenience option instead before we remove the old one.