superfluous host interfaces

[Vincent Hoffman-Kazlauskas]

On 27/02/2018 08:17, Harry Schmalzbauer wrote:
> Bezüglich Paul Vixie's Nachricht vom 27.02.2018 07:14 (localtime):
>>
>>
>> Harry Schmalzbauer wrote:
>>> Bezüglich Ruben's Nachricht vom 26.02.2018 11:34 (localtime):
>>>> On 26/02/2018 10:56, Harry Schmalzbauer wrote:
>>> …
>>>>> Another, personally very significant, reason is that you'll get a
>>>>> superfluous host interface for each if_bridge(4), which makes the
>>>>> output
>>>>> of plain ifconfig(8) kind of unreadable.
>>> …
>>>> By superflous host interfaces, do you mean the tap interfaces configured
>>>> for each vm together with the bridge interfaces they are "bundled" in?
>>>
>>> Additionally to the if_tap(4) ethernet host interfaces, you also get
>>> if_bridge(4) ethernet interfaces, named bridgeX if I remember correctly.
>>
>> you do not remember correctly.
> 
> Please see next para.
> 
> 
>>> [mm1.redbarn:amd64] egrep 'bridge|tap' /etc/rc.conf
>>> autobridge_interfaces="bridge0"
>>> autobridge_bridge0="tap* igb1"
>>> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7"
>>> ifconfig_bridge0="inet 24.104.150.210/27"
>>> ifconfig_bridge0_ipv6="inet6 2001:559:8000:cd::2/64 auto_linklocal up"
>>> ifconfig_tap0="up"
>>> ifconfig_tap1="up"
>>> ifconfig_tap2="up"
>>> ifconfig_tap3="up"
>>> ifconfig_tap4="up"
>>> ifconfig_tap5="up"
>>> ifconfig_tap6="up"
>>> ifconfig_tap7="up"
>>> [mm1.redbarn:amd64] ifconfig | egrep '^(bridge|tap)'
>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
>>> mtu 1500
> 
> That's what I mean; and it's named bridgeX, so memeory works in that
> case ;-)
> If you have only one "LAN" sharing all VMs, the one additional interface
> is neglectable.
> But my setups are different.
> I have almost as many different 802.11q separated ethernet collsion
> domains (VLANs) as VMs.
> That's what ESXi's portgroup is used for.  I need a separate switch for
> each VLAN (guests mustn't be able to sniff traffic etc.).
> 
Untested by me with bhyve but it looks like net/openvswitch
(http://www.openvswitch.org/) could be useful to you. As I say though
untested by me so cant speak for performance etc.

Vince


> 
> …
> 
>>> And using ng_bridge(4) instead of if_bridge(4) doesn't change the need
>>> for if_tap(4).  Only with vale(4) switches, bhyve(8) was able to provide
>>> virtio-net connection wihtout "spamming" the host's ethernet interface
>>> list (no tapX, no bridgeX).
>>
>> how did you get bhyve to use the netmap API rather than the tap
>> character special device?
> 
> Not me, peter commited the following:
> https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/pci_virtio_net.c?r1=288470&r2=293459
> 
> From that an, you don't need to add any host ethernet
> devices/interfaces, simply start your VM with e.g. "-s
> 1:0,virtio-net,vale0:1,mac=02:03:04:05:06:07".
> 
> As long as you created vale0, port [:]1 will be created dynamically and
> also destroyed after shutdown.
> 
> Again, to mimic ESXi's portgroups, you need one vale(4) switch for each
> VLAN.  And to uplink, you need to utilize if_valn(4), which forces
> netmap emulated mode.
> If you don't have/need VLANs, you can uplink a supported NIC via native
> netmap support, and additionally gain significatn efficiency improvements.
> Unfortunately, at least if_vlan(4) uplinks, don't work reliably.  After
> some short time, the complete network netmap(4) subsystem locks up.
> I talked with Vincenco Maffione (a member of Liugi Rizzo's netmap(4)
> team of University of Pisa) and fixing emulated netpmap mode on FreeBSD
> doesn't have really high priority there, since such a setup is
> considered as weak design.  For sure, it's a hack/workarround, but we
> don't have VLAN/portgroup support in vale(4) nor in byhve(8), and
> writing my own userland filter is beyond my scope.
> 
> -harry
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"
>