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
