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)
