Comment 3 for bug 1928113

Hello Christian,

Thank you for your quick and thorough response!

Em quarta-feira, 12 de maio de 2021 08:12:17 -03 você escreveu:
> Hi Thiago,
> the problem is that firewalld isn't in main and thereby not fully
> supported which means that libvirt (that is in main) can not depend on
> it - see [1] for some details.

Ah, I wasn't aware of that. Thanks for pointing out.

> Ubuntu's choice for this usually us UFW, but there is no UFW backend for
> libvirt.

I had a(n admittedly quick) look at UFW and I had the impression that it
aimed for simpler use cases than firewalld, and wasn't sure it would meet
my needs. This is why I went with firewalld.

But perhaps it would have solved my use case, I don't know.

> So the issue here is that today Ubuntus libvirt can't work with firewalld
> installed. To be able to work we'd need to promote firewalld wich might
> be unwanted for many other reasons. There might be a way in between if I
> can manage to get firewalld support built-in in a way that has no
> runtime dependency to firewalld from any of the packages in main. But I
> can't promise this will work out.

Yes, that would be awesome!

> I'll give it a try when I merge the next libvirt version and if it fails
> we need to reconsider getting firewalld promoted to main.

Thank you!

> If the latter
> also would be refused we'd at least want to make it fail more gracefully
> which might be tricky - e.g. a conflicts between libvirtd<->firewalld
> won't help you at all and you could have valid use cases for both just
> not everything would work.

At least for me in particular, a conflicts would be worse than the current
situation because I was able to get libvirt network going with the
workaround I mentioned earlier.

If all else fails, an alternative which would already help someone else in
a similar situation is to change the error message that libvirt shows about
firewalld to mention the workaround of adding a zone attribute to the
bridge node in the network XML definition.