On Mon, Jun 17, 2024 at 01:40:16PM GMT, Daniel P. Berrangé wrote: > On Mon, Jun 17, 2024 at 04:44:01AM -0400, Andrea Bolognani wrote: > > On Fri, Jun 14, 2024 at 07:52:55PM GMT, Daniel P. Berrangé wrote: > > > This is the behaviour we already had before the nftables backend > > > was created, and its not been a problem. There's no functional > > > reason why we should refuse to allow it to be defined, if the > > > binaries aren't needed until startup. > > > > But in the case of qemu:///session, or when we're not on Linux, we > > already know that there is no way for the network that's being > > defined to ever work. > > > > To me that's the same as allowing a guest to be defined, when the > > corresponding QEMU binary doesn't support some of the devices. Or > > when a firmware binary satisfying the constraints isn't available. We > > reject such configurations for guests, and it would just be > > consistent to do the same for networks. > > FWIW, I find the QEMU behaviour really unpleasant / hostile, when I'm > working with guests that reference a self-built QEMU, as the binary > often "doesn't exist", if I've cleaned by build temporarily. That makes things slightly annoying for developers, sure, but it's much more friendly towards users IMO. Getting an error sooner (define) rather than later (start) for situations where we know in advance that things can't possibly ever work is a lot better, which is also why libvirt erroring out is more user friendly than running QEMU and let if fail instead. > Overall, there's lots that could be improved in the network driver, > but for this, I'd really just like to focus on fixing the regression, > suc that we return to the behaviour we had historically. Clearly I'm not entirely happy with the behavior you're implementing with this, but I agree that it's still much better than leaving several common configurations completely broken. Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> -- Andrea Bolognani / Red Hat / Virtualization
