Re: epair(4)

W dniu 22.05.2025 o 23:06, Patrick M. Hausen pisze:
> Hi all,
>
>> Am 22.05.2025 um 22:15 schrieb void <void@f-m.fm>:
>> I think, from what other list members have written also, that many did as I did:- looked at the virtualization part of the handbook, found all what
>> was required there to get started, and thats it. They would probably not
>> (as I didn't) see the need to look at the advanced networking section if they
>> were only using a bridge with bhyve or similar.
> I have come to realise that there are two sides to this issue, both equally valid.
>
> How to configure and use if_bridge(4) correctly was documented from day one
> or very shortly thereafter.
>
> But still - for reasons I do not quite understand - more than one platform/wrapper
> development ignored that documentation.
>
> FreeNAS/TrueNAS surely did and from your posts I read that more jail/VM orchestration
> tools also "do it wrong".
>
> So I agree - we cannot place the burden on the users with a:
>
> "The documentation was on display in the bottom of a locked filing cabinet stuck in a
> 	disused lavatory with a sign on the door saying 'Beware of the Leopard.'"
>
> Which I am prone to do occasionally. Sorry about that.
>
> The technical discussion is simple. An IP address on a bridge member never
> was supported and never will be.
>
> The change that is currently discussed simply prohibits a setup that never
> was supported in the first place with the good intention to save people from
> foot shooting.
>
> I support your suggestion to *somehow* make some more noise about that.
>
> I have been screaming at walls for years about the broken setup of bridges
> in TrueNAS on the iX forum to no avail. Tickets in JIRA closed without action ...
> Stuff like that.
>
> Kind regards,
> Patrick
>
I think enough noise has been made. Regardless of its cause and 
intentions, this kind of noise isn't good for the FreeBSD community. I 
hadn’t planned to post further in this thread, but I’ve noticed the 
debate rising again like a phoenix from the ashes. Maybe it’s best to 
let it burn itself out.

Now is the time to focus on more productive efforts - improving tools 
like vm-bhyve, helping users with migration paths, and making sure the 
documentation is consistent and accurately reflects the current state of 
affairs.

Most importantly, there is a need to show the broader community (or at 
least not hide) that alternatives are available, such as ng_bridge(4), 
which allows for quickly setting up a network bridge for fast spinning 
up a bhyve VM for testing or running a VNET jail for short-term use.

Cheers
Marek