Date: Sat, 30 Aug 2025 07:14:23 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 289142] sysutils/vm-bhyve: public bridge fails on 15-CURRENT unless net.link.bridge.member_ifaddrs=1 is set Message-ID: <bug-289142-7501-kpWdvtyFN2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-289142-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-289142-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D289142 --- Comment #6 from Henryk Paluch <hpaluch@seznam.cz> --- (In reply to Michael Osipov from comment #5) I fully agree with your opinion but FreeBSD core team (and Linux Proxmox te= am) think otherwise. Main benefit of having DHCP IP assigned to NIC instead of bridge is that we= can manage vm-bhyve's bridges remotely without need of local console, because: 1. system normally boots with DHCP assigned address on NIC - remote access works 2. vm-bhyve init scripts (creates and connects its bridges if configured) 3. we can remotely connect to machine after boot and create new "public" sw= itch without IP and connect it to NIC. But when IP is assigned to Bridge we have kind of chicken and egg problem: 1. booting system where NIC is up but without IP address - only local conso= le working 2. we have to use local console to run vm-bhyve commands to create switch w= ith IP 3. only after point 2 - remote access will again start working (once devd r= ules are fixed). The only way to avoid this chicken and egg problem is to define these brid= ges (with IP address) system wide ("external" to vm-bhyve), but this reduces usefulness of existing vm-bhyve framework. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-289142-7501-kpWdvtyFN2>