superfluous host interfaces
freebsd at omnilan.de
Tue Feb 27 08:17:24 UTC 2018
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
>>>> 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_bridge0="tap* igb1"
>> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7"
>> ifconfig_bridge0="inet 126.96.36.199/27"
>> ifconfig_bridge0_ipv6="inet6 2001:559:8000:cd::2/64 auto_linklocal 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
If you have only one "LAN" sharing all VMs, the one additional interface
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.).
>> 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:
>From that an, you don't need to add any host ethernet
devices/interfaces, simply start your VM with e.g. "-s
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.
More information about the freebsd-virtualization