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

Reply via email to