network config not working on newer libvirt

[daggs]

Greetings Laine,

> You haven't said which distro, nor what is the libvirt exact libvirt
> version (probably won't matter in this case, but in general "libvirt
> x.y.z" is more useful than "latest stable libvirt").

you are correct, the previous os was debian 10 with libvirt 3, the new os is gentoo with libvirt 6.2.0

>
> If you have full connectivity once you've manually assigned IP
> addresses, then you don't have any routing problems, so that can be
> counted out. (Anyway, DHCP packets never go beyond the local network).
>
> In that case, you've most likely either got a firewall problem on host
> or guest, or a problem with your dhcp server.
>

iptables is installed on the host (required by libvirt because of the virt network features, from what I can see, it isn't running.
the guest is libreelec, somehow I don't think it has iptables installed or configured.

on the dhcp server (the other vm) I see this:
Sat Sep  5 00:33:25 2020 daemon.info dnsmasq-dhcp[2579]: DHCPDISCOVER(br-lan) 52:54:00:5a:4c:8c
Sat Sep  5 00:33:25 2020 daemon.info dnsmasq-dhcp[2579]: DHCPOFFER(br-lan) 10.0.0.40 52:54:00:5a:4c:8c

multiple times, it means that the server accepted the request and offers the correct ip to it but doesn't seem to get there.

>  From where? The host? or the guests?

I can ssh from one vm to another, without the manual ip, I cannot do it

>
> I would start troubleshooting by making sure that the dhcp server is
> running, and that you can communicate between the machine with DHCP
> server and the guest once a manual IP is assigned. Then use tcpdump or
> wireshark at different places on the path between those two to see how
> far the DHCP request is getting out, whether a response is being sent by
> the server, and if so how far the response is getting back (i.e. on the
> host, run tcpdump on the guest's tap device; if you see the DHCP request
> there, then run tcpdump on the bridge, if you see it there, run it on
> the tap device for the guest, if you see it there, then run tcpdump
> inside the guest; then check the dhcp server logs to see if it's
> receiving requests. While you're doing all of this, you can also be
> noticing whether or not a DHCP response is arriving at each step (and if
> you see the response, you can skip looking further ahead in the packet
> path, since you know by inference that it made it all the way to the
> DHCP server). Once you find the point that the packet is blocked, you'll
> be better able to determine why.
>
>

alright, I'll try that, thanks.

Dagg.