4:36 p.m.
On Thu, Jul 23, 2020 at 3:54 PM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
No, don't change it to 0. We need ip_forward enabled as you
say.
That's what I thought. I'm leaving it as it is.
Correct. The KVM host knows where the 10.2.2.1/24 subnet is - it
owns
it. The other hosts on your LAN don't know anything about 10.2.2.1/24,
so if they try to access VMs on that subnet, traffic will go to the
default route, aka your LAN router. It then has to know which KVM host
has the 10.2.2.1/24 subnet to send the traffic onwards.
Yep, again that's what I thought. For now I'll be leaving it as it is
because right now I just need the host to be able to communicate with the
VM's.
Yep, so that suggests a more fundamental problem with the KVM host
config.
Since ip_forward is confirmed as set to 1, I feel the most likely problem
is something related to the firewall rules.
Libvirt will create iptables rules to allow traffic. Tradititionally
this would have been sufficient, in iptables all rules are in the single
set of global tables.
If your OS distro has enabled "nft" to replace iptables though, things
become more tricky. In nft world there is no single set of global tables.
Any app using nft can define its own top level tables.
So while libvirt adds iptables rules to allow traffic, there is the
possibility that "nft" rules may none the less deny traffic.
In the specific case of distros using "firewalld", libvirt does some
further workarounds for this problem.
Overall though, I'd be investigating your firewall.
Okay, I think I've understood but how can I tell if my distro has 'nft'
enabled? Guess I'll ask down at their IRC channel and see if someone can
tell me.
Otherwise I think I'm fried because I googled it and I came out empty
handed.
It is helpful to add logging rules to your firewall immediately
before
any REJECT / DROP rules so you can spot packets being dropped. That
combined with tcpdump on the TAP devices should help you confirm
what is happening to traffic.
I don't have the faintest idea on how to set up logging rules, or worst,
how to get a tcpdump on my TAP devices and analyse the dump. I'd use
wireshark but I wouldn't know what I'd be doing to analyse the dump with it.
Often missed is that there are multiple instances of libvirtd. One global
instance that runs as root for privileged set ups, and then one per
user instance that runs unprivileged.
If you run "virsh" as non-root, you'll be querying the per-user instance.
virt-manager uses the privileged instance by default.
Try 'virsh -c qemu:///system netlist' instead, or simply run
virsh as root.
Got it.
Here's the output with sudo:
$ sudo virsh net-list
[sudo] password for ******:
Name State Autostart Persistent
--------------------------------------------
default active yes yes
routed active yes yes
$
$ virsh -c qemu:///system net-list
Name State Autostart Persistent
--------------------------------------------
default active yes yes
routed active yes yes
$
This means both network profiles are created, loaded, active and set up for
autostart.
Thanks for the headsup. I'll ask the Manjaro guys about the nft. Hopefully
they'll know if nft is installed and running.
Cheers,
Rui Correia