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=289142 --- 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 team) 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" switch 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 console working 2. we have to use local console to run vm-bhyve commands to create switch with IP 3. only after point 2 - remote access will again start working (once devd rules are fixed). The only way to avoid this chicken and egg problem is to define these bridges (with IP address) system wide ("external" to vm-bhyve), but this reduces usefulness of existing vm-bhyve framework. -- 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>