On Thu, Jul 23, 2020 at 3:54 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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
$
[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
