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.