Re: [libvirt PATCH 00/28] native support for nftables in virtual network driver
On 6/12/24 6:47 AM, Daniel P. Berrangé wrote:
On Wed, Jun 12, 2024 at 03:27:24AM -0700, Andrea Bolognani wrote:
> On Wed, Jun 12, 2024 at 09:57:15AM GMT, Daniel P. Berrangé wrote:
>> On Wed, Jun 12, 2024 at 01:54:47AM -0700, Andrea Bolognani wrote:
>>> Is there much of a difference between having an explicit noop backend
>>> that is checked for availability after all other ones, and simply not
>>> failing to initialize the driver if a backend can't be found?
>>
>> I actually sent a patch for the latter last night
>
> Awesome, thanks!
>
>>> I'm still unclear on how networking on FreeBSD could work at all
>>> until now. Aren't the iptables rules needed for guest connectivity?
>>> Or did I misunderstand their purpose?
>>
>> It wouldn't have worked, but the problem is that we now kill the
>> entire libvirtd startup, instead of successfully starting a (broken)
>> network driver. Both are broken, but now the brokenness has spread
>> to the bits that do matter.
>
> I get that, it's just that I'd be extremely surprised to learn that
> guest network connectivity hasn't worked on FreeBSD all this time.
> Surely that can't be right! Roman, what am I missing?
This is only the libvirt virtual network backend. I presume BSD hosted
guests could just use one of the other network backend options.
Based on the wording of Roman's initial message, I wondered if possibly
people had been using the virtual network driver with <forward
mode='open'/> - this wouldn't ever call any firewall functions, so it
should succeed. I'm pretty sure none of the other network types are
supported on BSD (macvtap/direct, or pools of SRIOV VFs used via VFIO
device assignment).
(I had asked about this in a reply night before last, but I think it
wasn't seen by anyone because I replied to his first message that was
accidentally sent to the old list and I'd iniially just hit reply
(sending my reply to the old list too), then re-sent the message to the
new list, but I think my email client changed the In-Reply-To: so it
wasn't properly threaded and appeared separate from the rest of the thread.)