Re: [libvirt PATCH 00/28] native support for nftables in virtual network driver
On Thu, Jun 13, 2024 at 06:24:00PM GMT, Roman Bogorodskiy wrote:
Laine Stump wrote:
> On 6/12/24 2:32 PM, Roman Bogorodskiy wrote:
> > So basically all the mechanics like creating tap devices, bridges,
> > serving dhcp, etc, all these work for me. On top of that I had a few
> > iterations of manual firewall configurations (with both ipfw and pf)
> > to implement NAT on guests.
>
> Okay, so essentially it was effectively <forward mode='open'/> (since
the
> only difference is the lack of libvirt-added firewall rules).
Yes, I've changed it to mode='open' and it still works for me, i.e. I
have host<->guest connectivity.
So it would make more sense to change the default to 'open', at least
until nat is not supported. I think I'd better do that on the packaging
level.
If you're touching the package, can you also look into the other
question that I've raised about it? Namely that, since the QEMU
driver is compiled out by default, the same should probably be the
case for the network driver too. If someone goes and builds the port
locally with QEMU support enabled, then and only then the network
driver should be included.
Honestly I'm not entirely sure it makes much sense to have the
network driver and especially the default network if you need to
bring your own firewall rules, but that can be a separate discussion.
--
Andrea Bolognani / Red Hat / Virtualization