On 05/04/2016 08:40 AM, lejeczek wrote: Is virbr0 created by libvirt as part of one of its "virtual networks"? If so, why are you using dhcpd rather than the dnsmasq that libvirt already runs for it (and how are you managing to terminate the dnsmasq process run by libvirt so its listening socket doesn't conflict with the listener setup by dhcpd?) If virbr0 is created by libvirt, it's already starting a dnsmasq process to handle dhcp requests, so you don't need (and shouldn't be able to start) dhcpd listening on it. If virbr0 *isn't* created by libvirt, then the change to systemd's configuration won't have any effect.

On 05/12/2016 12:23 PM, lejeczek wrote: Now that I see the libvirt network definition, I see that you don't have any <ip> in it. So how does virbr0 *ever* get an IP address (since apparently this is necessary for dhcpd to listen on it)? (Hmm - or is there an <ip> element, but you just haven't included it in your snipped bit of the network definition? If so, you omitted a very important part of the puzzle!) Ah right, since there is no <ip> for the network (? right?), not only will dnsmasq not listen for dhcp requests, but it simply won't start dnsmasq at all. (if you do have an <ip> element but no <dhcp>, then dnsmasq will be started, but only listen for dns requests, so either way I now understand why dhcpd is able to listen). (NB: There currently isn't a way to disable dhcp *and* dns listeners while simultaneously also setting up an IP address). Note that if there is no <ip> element, "<forward mode='route'/> in this config is nonsensical - since there is no ip address associated with the network, there is nothing to use for setting up iptables rules (which are all based on a combination of bridge name and IP address/netmask). I disagree that libvirt is doing anything wrong. I really think it's beyond the scope of libvirt to try to determine if it must complete its network startup prior to allowing your dhcpd to start - once you start, there's no end to the packages that might require libvirt's networks to be completely started in order to listen on a bridge created by libvirt, but we shouldn't be hard-coding into every host's startup dependencies to make every service that sets up a listener socket synchronously wait for libvirtd startup to complete - that would unnecessarily create a delay on thousands of systems that don't need it (and could potentially create some sort of circular dependency; I haven't checked) I think that instead of using libvirt to create this simplistic bridge, you should just setup the bridge in your host's normal network config, i.e. in /etc/sysconfig/network-scripts create the following file (btw - take my advice and don't use a name starting with "virbr" when you switch to setting up a bridge in the host system config. It will lead to confusion at best, since libvirt-created bridges use virbrX, and if anyone you ask for help sees a name starting with virbr they will assume it is a bridge created by libvirt): ifcfg-br0: DEVICE=br0 ONBOOT=yes TYPE=Bridge STP=on DELAY=0 IPV6INIT=no (include any IPv4 config here) If you want to continue referring to that bridge as a network in libvirt domain configs (ie if you want to keep using <interface type='network'> .... <source network='mynet'/>...") then change the network definition like this: <network> <name>mynet</name> <forward mode='bridge'/> <bridge name='br0'/> <network> This type of network definition won't create the named bridge, but will instead expect that such a bridge (created by someone else, usually the host system network config) already exists, and connect any guest tap devices to that bridge. Because it's now the host system network service (or Network Manager service) that is creating the bridge rather than libvirtd, it will be available when the dhcpd service starts up, so you won't have the failure you have now.

On 05/13/2016 04:31 AM, lejeczek wrote: I don't need to try it to understand that it likely won't work reliably, because dhcpd.service doesn't depend on libvirtd being completely started, so it could be trying to start before libvirtd has been able to completely configure the new bridge interface. The simplest/ most reliable way to fix this is by moving the bridge setup to the system network config, as I detailed below.