0

I'm about to migrate a Debian Stretch host using qemu-kvm to Debian Buster.

I've seen people complaining on the Internet about issues due to nftables becoming default in place of iptables and libvirt using iptables rules. Rules automatically written by libvirt are not understood by nftables.

I can move back to iptables after the upgrade if needed:

# update-alternatives --set iptables /usr/sbin/iptables-legacy
# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# update-alternatives --set arptables /usr/sbin/arptables-legacy
# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Would that be enough to get my system running?


From the docs and this GH comment firewalld support was added in libvirt 5.1.0. And it is unclear to me whether the minimal firewalld version required for the whole thing to work is 0.6.0 or 0.7.0.

Here are the versions shipped by Debian:

firewalld

  • stretch 0.4.4.2-1
  • buster 0.6.3-5
  • bullseye 0.7.2-1

libvirt-daemon

  • stretch 3.0.0-4+deb9u4
  • buster 5.0.0-4
  • bullseye 5.6.0-2

So I guess things should be fine in bullseye. Except for the existing rules.

Is the following plan the way to go?

  • Migrate to Buster and stick to iptables using the update-alternatives trick above.

  • When Bullseye is out, migrate and stick to iptables for now.

  • Translate rules manually and migrate to nftables later.


Edit:

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Local network
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
    bridge_ports eth0
    bridge_maxwait 0
    address 192.168.10.27
    netmask 255.255.255.0
    gateway 192.168.10.1
    dns-nameservers 192.168.10.8 192.168.1.9 8.8.8.8
    dns-domain my_domain.local
    dns-search my_domain.local

# External network
auto eth1
iface eth1 inet manual

auto br1
iface br1 inet manual
    bridge_ports eth1
    bridge_maxwait 0
  • @A.B You're right about firewalld, I'm not using it. I got mislead by the phrasing "libvirt 5.1.0 has native integration with firewalld and as such works well with the nftables backend." in github.com/firewalld/firewalld/issues/…. This could be a wrong lead. – Jérôme Dec 9 '19 at 11:20
  • @A.B are you implying that I'm overthinking it and it should work fine out of the box? I didn't find much posts about such issues, so maybe they only affect corner cases. – Jérôme Dec 9 '19 at 11:24
  • Thaks @A.B. We setup a bridge in the host. The host had two network interfaces, one on the local network, the other one directly connected to the outside world. The host is only accessible internally, but the guest VMs inside are accessible from the Internet but not from the local network. I added the network config file to the question. We didn't do anything related to firewalling. And I don't think we did anything specific about firewall rules when configuring virtual machines. – Jérôme Dec 9 '19 at 13:12
  • Are there any iptables rules automatically created by libvirt? Where would they be? How can I check they work with nftables (or nftables + compat layer, this iss a bit blurry to me)? Is the compatibility be maintained temporarily? Do I need to convert some rules on the long run? – Jérôme Dec 9 '19 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.