From owner-freebsd-virtualization@freebsd.org Tue Feb 27 20:09:59 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 459EEF24078 for ; Tue, 27 Feb 2018 20:09:59 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id BCFA06D1A4 for ; Tue, 27 Feb 2018 20:09:58 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from Vincents-MacBook-Pro-2.local (vhoffman.plus.com [81.174.148.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by unsane.co.uk (Postfix) with ESMTPSA id 917C53018D for ; Tue, 27 Feb 2018 20:09:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=unsane.co.uk; s=251017; t=1519762192; bh=Lq+JclnLv81fKeDcxSjQe5D/SHy5oK77OhxigB2BbKQ=; h=Subject:To:References:From:Date:In-Reply-To; b=ZsoSzzdXbyrKIElHcdpRZtZcpu+VULfH6RNghwrycGEOYOvflaJ7lWOJi0+qWXGyR 9USiKNoUYxERLtzV62J6E12W5UkxW9rxiUz2DEQepDVljyK5J+9WSyHwsqIGRdXXtb 0W5n6om/JnqxiFuoTbAymfP8keY0gf5s5aox7Le0= Subject: Re: superfluous host interfaces To: freebsd-virtualization@freebsd.org References: <20180225131401.GA3138@v007.zyxst.net> <5A93CEB6.1080406@omnilan.de> <5A93D9D0.4090804@omnilan.de> <54f9019e-6e86-8e10-32d7-9f14d159bb0a@osfux.nl> <5A93F9DE.9090908@omnilan.de> <5A94F730.7040009@redbarn.org> <5A95140E.8030909@omnilan.de> From: Vincent Hoffman-Kazlauskas Message-ID: Date: Tue, 27 Feb 2018 20:09:52 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5A95140E.8030909@omnilan.de> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 20:09:59 -0000 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 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" >