From nobody Wed May 21 16:12:08 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2bzH3Dggz5w8Wy for ; Wed, 21 May 2025 16:12:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2bzH29CXz3MHM for ; Wed, 21 May 2025 16:12:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747843931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mwveSdMoSznpa57V6PlWbBHHuIcbWwzx215ng/mWaoI=; b=xUd4r0pB1/zcnQP596YJbOv/i/Vi5EgKnndFp3Y3l7AzE8xh+gid45dCmguvoSgarPZp95 GsUtv9K9J+nJZG7jBXN7TFHo7gSkjHI9ZeZOln2uklueCNbB/clc/Tt1QzaYXxVsgw9ibV 3nMH35sXeWyGS6wy7poy+y/WD3qLq4o0jqUReUlcfoyLmfaUQ/eLx1fX5VkVd3spZYJoBL WXmrJIUmb7HZ/cDhC3yR+iOMOwwgWsqdEy8eLm0xuVVTLcBEy/AEFChQxqhCZB+bBfgONh 80WXiRfmbu7bpazPnpX6+TMsD3jP/pQPP2ieH4Gbf+XuIc+/sHuOi1WsHVR/uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747843931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mwveSdMoSznpa57V6PlWbBHHuIcbWwzx215ng/mWaoI=; b=wM14QbJ1koEYW/Q4W6L/gycpcOawFy08BhUKoO/H2UjoEl2h5frdEot7sxo9y+T7cu+hj0 6fvZO1iYvMh9LsTK0GVkf4yjJCZTmHlyRWHW/L7OuOgMt3H59DEvFadM6Xcn5/l0RrXJ4I b1OpgjWN6RLeOt+Zof6EYzO0QsV/agkvbOzBeAsdt7BTMPuC40lC+UOAY6ybl34wjU56xj GaP1Z0gShkPyfhOcrFjZcaiTbVd8zJBT7x3yuEAp0Qr4627DEts2yikQT00czzj9u7tgme Y/XlF9czXxlYBIEDiYtjX/QNPtp8iT1qDZxZfiAeDunTbViCuTqODmDhfTBbOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747843931; a=rsa-sha256; cv=none; b=eySsnBngU35KVTSMIZY1A2PEAHWyeld9kpS7YotC6ypXGEHiWER8d0H+3RIx5L0WS9DUL2 L3MtdoVr7j3Nn0KMWDaCHzGDvaUpa07xZPMqixINEPHkUqQrPgNcWiRpjxlNGtdxpB2KPH aPvArW0BESCrhLNxvkhfnVLQCMMs8XYOu03b93vBkTXhJZrAeU5mmb6VCKkO/BAP+qbduH fIQR4KlCFqFBG8v+fQs6C1N1S6QgqhM2vS3Yf8XgJLCRfDA1BtQwb6N2Ozh7M1vCTkaQMR fYdaplHJ3EGV5SnW4Ew3Ti2nKBLgTOtgfMs3M7KQNNo/qVkX8Z8GVyczzsw2vA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2bzH06hkz8RQ for ; Wed, 21 May 2025 16:12:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <6433db6a-e106-42ee-9276-c53b56a13bd1@FreeBSD.org> Date: Wed, 21 May 2025 19:12:08 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: =?UTF-8?Q?Re=3A_HEADS_UP=3A_15=2E0-CURRENT=2C_change_to_bridge=284?= =?UTF-8?Q?=29_might_break_some_network_configurations_with_=E2=80=9CInvalid?= =?UTF-8?B?IGFyZ3VtZW504oCd?= To: freebsd-current@freebsd.org References: <3647A8FC-FED1-4539-8BDE-CACCF6A5FC0A@FreeBSD.org> Content-Language: en-US From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21/05/2025 18:01, void wrote: > This bhyve host was set up following instructions from the bhyve section of the > handbook. I've just checked and no mention is made of the > new requirement in section 24.7.1 of the handbook at > https://freebsd.org/handbook > > So, if a lot of people run bhyve guests as described > then more people are going to be affected than one might initially > presume. Just in case, here is the full Handbook link: https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-bhyve-prep I am quite sure that a lot of hosts with VMs are configured that way. Mine are. And I saw on developers@ other people reporting the same kind of setup. I must admit that in my rational mind I understand that a bridge is a bridge, but I always felt that a bridge combining several physical interfaces (and thus physical LANs) and/or maybe some VLAN interfaces is different from a bridge that combines a single physical or VLAN interface with several virtual interfaces (like tap or epair) that are connected to VMs. I always knew to assign an IP address to the first kind of a bridge, never to its members. But in the second case, it felt that the physical interface is the primary interface. It's *the* network interface. It must be configured fully. And the bridge is "ephemeral". Maybe I won't start any VMs and won't configure the bridge at all. Why always have that bridge? Or why change the main networking configuration when I decide to create that "VM bridge"? And this view is reflected in Handbook and also in some external tools for VM management. Take for instance vm-bhyve which seems to be a pretty popular "front-end" to bhyve. Its quick start has these steps which are equivalent to what Handbook has: 7. vm switch create public 8. vm switch add public em0 Seeing both sides of the things I am not sure what to propose here. But I certainly do not enjoy the thought that I need to change a host's network configuration in case I just want to run a VM and to bridge it to the LAN. Or I'd have to pre-configure a bridge (with a single member, initially) on every host where I might want to configure a bridged VM later. vm-bhyve links: - https://github.com/freebsd/vm-bhyve - https://github.com/churchers/vm-bhyve/wiki/Virtual-Switches -- Andriy Gapon