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.
