superfluous host interfaces
freebsd at omnilan.de
Wed Feb 28 11:51:19 UTC 2018
Bezüglich Vincent Hoffman-Kazlauskas's Nachricht vom 27.02.2018 21:09
> 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):
>> 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.
I made a local OVS port which incorporated netmap support, but I was
told that OVS lost attraction for the netmap team, when I tried to solve
some problems, since netmap patches from upstream were highly linux
specific and considered obsolete.
Intel contributed some DPDK resources, which look interesting (and seem
to perform great on linux).
But OVS itself would need more resources to get better support on
FreeBSD and additionally a huge ammount of resources to get DPDK|netmap
In 10GE days, OVS without netmap|DPDK doesn't make much sense imho.
We have netmap/vale(4), which could be extenden to cover a small subset
of OVS feature, with porbably moderate ammount of resources.
So in my opinion, for those using bhyve(4) as slim hypervisor, the not
very slim OVS doesn't fit well overall, especially due to perfomance
A portgroup/vlan filter+manager on top of vale(4) was a much better
companion for bhyve(4). I'll start immediately when retireing (learing
to use whatever debugger will be arround then...) ;-)
More information about the freebsd-virtualization