From owner-freebsd-virtualization@freebsd.org Tue Feb 27 06:14:14 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 3CC6CF283B7 for ; Tue, 27 Feb 2018 06:14:14 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7FCE84513 for ; Tue, 27 Feb 2018 06:14:13 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:559:8000:c9:c479:6a5b:b7d2:c3d5] (unknown [IPv6:2001:559:8000:c9:c479:6a5b:b7d2:c3d5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4531E7594B; Tue, 27 Feb 2018 06:14:11 +0000 (UTC) Message-ID: <5A94F730.7040009@redbarn.org> Date: Mon, 26 Feb 2018 22:14:08 -0800 From: Paul Vixie User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Harry Schmalzbauer CC: Ruben , FreeBSD virtualization Subject: Re: superfluous host interfaces 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> In-Reply-To: <5A93F9DE.9090908@omnilan.de> Content-Type: text/plain; charset=windows-1252; format=flowed 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 06:14:14 -0000 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. > [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 > tap0: flags=8943 metric 0 mtu 1500 > tap1: flags=8943 metric 0 mtu 1500 > tap2: flags=8943 metric 0 mtu 1500 > tap3: flags=8943 metric 0 mtu 1500 > tap4: flags=8943 metric 0 mtu 1500 > tap5: flags=8943 metric 0 mtu 1500 > tap6: flags=8903 metric 0 mtu 1500 > tap7: flags=8903 metric 0 mtu 1500 the only bridge i see is the one i statically defined. > 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? -- P Vixie