Andrea Bolognani wrote: > 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. Hm, I think the network driver is quite usable without QEMU, e.g. I use it with bhyve. I also find it quite useful even without firewall rules. Most of the time internal connectivity is enough for my guests. Configuring NAT on per-network basis is also fairly easy. For more advanced scenarios hooks could be used, though I haven't done that specifically. For now I'm inclined only to update 'nat' to 'open' as 'nat' is a misleading configuration and was working only by incidence. Roman > -- > Andrea Bolognani / Red Hat / Virtualization >
