Settings "firewall_backend = nftables" in /etc/libvirt/network.conf
worked. Thank you.
I dont know what the Issue yesterday was. When I remember correctly I
tried setting the firewall backend; I also played around with
"update-alternatives --edit iptables", but that seemed not relevant.
Again, thank you :)
On 3/31/26 04:15, Laine Stump via Users wrote:
On 3/30/26 6:25 AM, [email protected] wrote:
Thank you for your answer, unfortunately I already had the libvirt-
daemon-driver-network package already installed.
There also was, as you mentioned, a predefined default network.
When I try to start the default network, or any other network with
virsh, I still get
error: Failed to start network virbr0
error: internal error: Failed to run firewall command iptables -w --
table filter --list-rules: iptables v1.8.11 (nf_tables): table
`filter' is incompatible, use 'nft' tool.
This ^^^ is the important message. In any non-ancient kernel iptables
is implemented via a "glue" layer that turns any iptables rules into
nftables rules (nftables is the modern successor to iptables. While
nftables can have any number of separate tables of rules, iptables
only has 3 tables - the "filter" table, the "nat" table, and the
"mangle" table (I think I'm remembering that last one correctly...)
When iptables is being emulated with nftables, it creates three tables
with those names in nftables, and puts nftables translations of any
iptables rules into those tables. The error message above shows up
when some piece of software *other than iptables* inserts nftables
rules into one of the 3 tables being used by the iptables emulation -
iptables itself then tries to do something with the table (in this
case just list the rules), and when it encounters a rule that it
doesn't expect, it throws up its hands in failure.
So, this means that you have some software running on that OS that has
used an nft command to add a rule to the table named "filter", and
iptables doesn't like it. And unfortunately your libvirt network
driver is using iptables command for traffic filtering and nat.
There are two solutions to this problem: 1) figure out what that other
misbehaving software is and fix it, or 2) (the preferred solution) if
your libvirt version is new enough (v10.0.0 or newer) switch libvirt
to use nftables instead of iptables - the other software will still be
misbehaving and render all iptables commands unusable, but also
libvirt won't be using iptables commands anymore.
To see if the libvirt on this system supports using nftables, look for
a file named /etc/libvirt/network.conf. If that file exists it will
have a setting "firewall_backend" - uncomment the line for that
setting and change it to 'firewall_backend = "nftables"'.
If /etc/libvirt/network.conf doesn't exist, then you'll need to figure
out what software is improperly using the filter table of nftables,
and fix it. You *might* get a clue by looking at the output of "nft
list ruleset". My guess would be that some software like docker or
podman had previously been using iptables, but then switched to using
nftables by just adding exactly the same rules in the same table but
via the "nft" command rather than the "iptables" command.
Furthermore, in the logs of libvirtd I see:
Unable to open /dev/kvm: No such file or directory
This part is unrelated to the virtual network starting. The virtual
network driver doesn't use KVM - only the qemu driver uses it.
internal error: Failed to run firewall command iptables -w --table
filter --list-rules: iptables v1.8.11 (nf_tables): table `filter' is
incompatible, use 'nft' tool.
Cannot get interface flags on 'virbr0': No such device
error destroying network device 'virbr0': No such device
This message is just a side effect of cleaning up after the iptables
command failed.
The error seems widespread, but all the solutions (for example
loading the kvm_intel kernel module) do not work for me.
Yeah, that will do nothing for virtual networks because it isn't used
by virtual networks - the kvm module is used for hardware
virtualization support of various CPU functions, and is completely
100% irrelevant for the virtual network driver.
On 3/24/26 22:51, Laine Stump via Users wrote:
On 3/24/26 12:28 PM, [email protected] wrote:
Hello,
I want to set up a NAT network inside a VM (so far as I understand,
the name for that is nested virtualization).
A virtual network (including one with NAT enabled) doesn't require
"nested virtualization" support (which is a term normally used to
refer to hardware *CPU* virtualization for L2 nested VMs that are
run within an L1 virtual machine (that is a VM running on a physical
host)). A libvirt "virtual network" is just a simple way to start up
the following group of functionality as a unit:
1) a Linux host bridge device (which can be used to connect tap
devices to each other and then forward their traffic to a physical
network using IP routing
2) an instance of dnsmasq, to provide 2a) DNS and 2b) DHCP services
to anything connected to the hostbridge in (1)
3) proper packet filtering rules (i.e. nftables or iptables) to
permit/block traffic between the devices connected to the bridge and
the host + physical network.
It is called a "virtual" network because it doesn't have any
physical components, but it doesn't have anything to do with the CPU
virtualization of KVM (which is what "nested virtualization" refers
to).
Unfortunately I only have Shell Access to the VM, and am not
hosting it.
This shouldn't be a problem (for creating a virtual network within
your guest VM anyway).
I installed debian.
The output of `uname -a`: Linux kvm1 6.12.74+deb13+1-amd64 #1 SMP
PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
When I run `kvm-ok` it says "INFO: Your CPU does not support KVM
extensions KVM acceleration can NOT be used".
When I try to load `kvm_intel` into the kernel (even with nested=1
option), it says "modprobe: ERROR: could not insert 'kvm_intel':
Operation not supported".
I can't start a network, there is no `/dev/kvm` device.
None of the above is a roadblock to creating a libvirt virtual
network within the guest VM. It *will* prevent you from running
nested VMs with accelerated CPU virtualization (you can still run
nested VMs that use TCG i.e. software CPU virtualization, but you
will be very underwhelmed by the results).
I installed libvirt with `apt install --no-install-recommends qemu-
system libvirt-clients libvirt-daemon-system`.
I don't use debian, so I don't know which libvirt subpackages those
pull in, but for libvirt virtual network management, you need to
have the package libvirt-daemon-driver-network installed - your
inability to create a virtual network is because that package is
missing.
(Additionally if you install libvirt-daemon-config-network that will
add the canonical libvirt "default network" to your config, and
attempt to autostart it when your guest starts. You can either use
it as-is, or edit it with "virsh net-edit" to change the subnet it
uses.)
Is there a way to enable libvirt support? For me, or the admins
that host the VMs?
As for *CPU* virtualization (aka KVM), that's not something that you
can enable from your guest VM by itself. To enable nested virt for
your guest (and others), the admins of the physical host should look
at something like this for guidance:
https://docs.fedoraproject.org/en-US/quick-docs/using-nested-
virtualization-in-kvm/
Note that any nested guest you may have created prior to enabling
nested virtualization will have been setup for software
virtualization, and remain that way until you change its config or
simply recreate it with nested virt enabled.
(NB: I don't know when that was last updated, and personally don't
ever use nested virt so I'm not certain if those are the best
instructions)
