Description of problem: When disabling the boot menu, and with a VM that loads quickly (disabled grub's 5 seconds timeout), it appears that libvirt's DHCP server may not be ready to respond to DHCP requests. I am running multiple VMs, concurrently, each with 4 NICs - and some of them fail to get an IP at a time. By simply restoring the boot menu, this problem goes away. Version-Release number of selected component (if applicable): libvirt-2.2.0-2.fc25.x86_64 How reproducible: Sometimes. Steps to Reproduce: 1. Launch multiple VMs, with quick boot. Actual results: Some interfaces do not get an IP. Expected results: All IPs get an IP.
If this is a setup using a libvirt-managed virtual network, dnsmasq is started and running all the way back when the libvirt network is started (which usually happens when libvirtd is first started after booting the host), so it's not likely that the problem is the DHCP server (which is in dnsmasq) not being ready. A more common problem is that the dhcp client in the guest times out while the guest's tap interface (its connection to the libvirt network's bridge) is still in the STP forward delay period (during which any guest network traffic is discarded rather than being forwarded). If you have STP enabled in the network, does it have delay='0'? If you reboot the guest (without shutting it down, which would also detach/reattach the tap device thus restarting the STP delay) does it then work? If your setup isn't using a libvirt-managed network, then neither the DHCP server nor the STP forwarding delay are under libvirt's control, so the solution lies elsewhere.
Closing - I think we have found an issue that might explain it - we had duplicate IPv6 addresses configured for the GWs of different networks. In any case, it does not reproduce now that we've fixed that - so hopefully it was that.