Please enable firewalld support in libvirtd

[Thiago Jung Bauermann]

I use the firewalld package to manage my firewall configuration. I just installed the libvirt-daemon set of packages (see below) and libvirtd registers this error in the journal:

libvirtd[1063]: internal error: firewalld is set to use the nftables backend, but the required firewalld 'libvirt' zone is missing. Either set the firewalld backend to 'iptables', or ensure that firewalld has a 'libvirt' zone by upgrading firewalld to a version supporting rule priorities (0.7.0+) and/or rebuilding libvirt with --with-firewalld-zone

Looking at the firewalld status there is indeed no 'libvirt' zone so the problem reported is real.

As I understand it, the 'iptables' firewalld backend has been deprecated a couple of years ago in favor of the 'nftables' backend, so setting the backend to a deprecated one isn't a good solution.

In the libvirt package's debian/rules I see:

WITH_FIREWALLD = -Dfirewalld=disabled

So firewalld support is indeed disabled in Ubuntu.

Could you please enable it?

This is on Ubuntu 21.04.

Relevant package versions:

firewalld 0.9.3-2ubuntu1
libvirt-daemon 7.0.0-2ubuntu2
libvirt-daemon-config-network 7.0.0-2ubuntu2
libvirt-daemon-config-nwfilter 7.0.0-2ubuntu2
libvirt-daemon-driver-qemu 7.0.0-2ubuntu2
libvirt-daemon-system 7.0.0-2ubuntu2
libvirt-daemon-system-systemd 7.0.0-2ubuntu2

[Thiago Jung Bauermann (thiago-bauermann)]

More information I should have mentioned earlier:

The impact of this bug is that libvirt can't start the default network:

bauermann@popigai:~$ virsh -c qemu:///system net-start default
error: Failed to start network default
error: internal error: firewalld is set to use the nftables backend, but the required firewalld 'libvirt' zone is missing. Either set the firewalld backend to 'iptables', or ensure that firewalld has a 'libvirt' zone by upgrading firewalld to a version supporting rule priorities (0.7.0+) and/or rebuilding libvirt with --with-firewalld-zone

bauermann@popigai:~$ echo $?
1

The workaround is to add a zone="trusted" attribute to the bridge node of the network XML definition:

<network>
  <name>default</name>
  <uuid>d20d5db0-4a01-4422-8bcb-8b582d019356</uuid>
  <forward mode="nat">
    <nat>
      <port start="1024" end="65535"/>
    </nat>
  </forward>
  <bridge name="virbr0" zone="trusted" stp="on" delay="0"/>
  <mac address="52:54:00:13:28:6a"/>
  <ip address="192.168.122.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.122.2" end="192.168.122.254"/>
    </dhcp>
  </ip>
</network>

[Christian Ehrhardt  (paelzer)]

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.

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

Being on iptables wasn't so much of a discontinuation problem as iptables nowadays is provided by nftables/ebtables. But firewalld itself no more wants iptables that is true.

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.

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. 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.

Hmm, it feels there is too much uncertainty - I hope I can manage to build it in a non-dependent way because all other options sound lengthy.

[1]: https://wiki.ubuntu.com/MainInclusionProcess

[Thiago Jung Bauermann (thiago-bauermann)]

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.

[Christian Ehrhardt  (paelzer)]

The dependencies already are (and would stay)
  iptables (>= 1.8.1-1) | firewalld
from Package: libvirt-daemon-system.
This is very much the same in Debian where we have kept it enabled.
Therefore I can enable the support in libvirt without pushing anything into main that isn't supposed to be there.

Thanks for the ping here, working on this as part of libvirt 7.4

[Thiago Jung Bauermann (thiago-bauermann)]

Em quinta-feira, 17 de junho de 2021, às 10:07:39 -03, Christian Ehrhardt 
escreveu:
> The dependencies already are (and would stay)
> iptables (>= 1.8.1-1) | firewalld
> from Package: libvirt-daemon-system.
> This is very much the same in Debian where we have kept it enabled.
> Therefore I can enable the support in libvirt without pushing anything
> into main that isn't supposed to be there.
>
> Thanks for the ping here, working on this as part of libvirt 7.4

This is excellent news! Thanks for working on this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 7.4.0-0ubuntu3

---------------
libvirt (7.4.0-0ubuntu3) impish; urgency=medium

  * d/t/smoke-lxc: skip if cgroup v1&v2 are present (systemd 248
    was not enough)

libvirt (7.4.0-0ubuntu2) impish; urgency=medium

  * d/t/smoke-lxc: skip before systemd 248 due to a known bug (LP: #1934966)

libvirt (7.4.0-0ubuntu1) impish; urgency=medium

  * Merge v7.4.0 from upstream,
    among a lot of new features and fixes this closes a few of issues
    reported against Ubuntu
    - Toleration for qemu >=6.0 handling of props (LP: #1932264)
    - Persistent vfio-ccw device assignments (LP: #1887929)
    - Drop patches that are upstream in v7.4.0
      - d/p/b/meson-Fix-cross-building-of-dtrace-probes.patch
      - d/p/b/apparmor-let-image-label-setting-loop-over-backing-files.patch
      - d/p/r/systemd-Revert-remote-Add-libvirtd-dependency-to-virt-gue.patch
      - d/p/u/lp-1913266-*: add vsock options to be usable with s390x
      - d/p/u/lp-1921754-*: EPYC-Rome-v2
      - d/p/u/lp-1921880-*: EPYC-Milan
    - d/libvirt-clients.install: completions no more are symlinked to vsh
    - Revert "disable firewalld support (universe dependency)"
      This does not add a runtime dependency and while firewalld isn't in
      main that way users can install and use it from universe.
      (LP: #1928113)
    - d/libvirt0.symbols: bump symbol versions for 7.4.0
    - d/rules: disable the now auto-built vstorage backend
    - not-installed: split daemon man pages are no yet installed

 -- Christian Ehrhardt <email address hidden> Thu, 08 Jul 2021 14:20:53 +0200