libvirt users - May 2016 - Re: dhcpd (via systemd) @boottime which does not wait for the interface..

On Fri, 2016-05-06 at 07:41 -0400, Laine Stump wrote:
> On 05/04/2016 08:40 AM, lejeczek wrote:
> 
> > hi users
> > 
> > 
> > I have my dhcpd to serve nothing but virbr0 (libvirt), OS is Centos
> > 7.2
> > Dhcpd would not start, complaining like this:
> > 
>  
> 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?)
yes, set up like this: 
 <forward mode='route'/>
  <bridge name='virbr0' stp='on' delay='0'/>
It really is simple plain vanilla setup, maybe not common but simple,
should be easy to reproduce: libvirtd's only one virbr0 and dhcpd to
listen only on this iface.
> 
>     
> 
>     > > 
> >       > > 
> >         
> > 
> >         
> > 
> >         > > No subnet declaration for virbr0 (no IPv4
addresses).
> > 
> >         > > ** Ignoring requests on virbr0.  If this is not what
> > 
> >         > >    you want, please write a subnet declaration
> > 
> >         > >    in your dhcpd.conf file for the network segment
> > 
> >         > >    to which interface virbr0 is attached. **
> > 
> >         
> > 
> >         
> > 
> >         > > and systemctl -l shows:
> > 
> >         > > ...
> > 
> >         > > systemd[1]: start request repeated too quickly for
> >           dhcpd.service
> > 
> >         > > ...
> > 
> >         
> > 
> >         
> > 
> >         > > but suffice to restart dhcpd and all works!
> > 
> >         > > I'v customized systemd's service conf,
I've put:
> > 
> >         
> > 
> >         
> > 
> >         > > After=libvirtd.service
> > 
> >         > > Requisite=libvirtd.service
> > 
> >       
> > 
> >     
> 
>     
> 
>     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.
> 
>     
> 
>     > > 
> >       > > 
> >         
> > 
> >         
> > 
> >         > > but this did not help.
> > 
> >         > > Would you share your thoughts? Systemd list say
it's
> >           libvirt (wrong)doing.
> > 
> >         > > many thanks.
> > 
> >       
> > 
> >     
> 
>     > > 
> >       > > 
> >         > > L.
> > 
> >       
> > 
> >       
> > 
> >       > > 
> >       
> > 
> >       > > _______________________________________________
> > libvirt-users mailing list
> > 
libvirt-users@redhat.com> > 
https://www.redhat.com/mailman/listinfo/libvirt-users
> > 
> >     
> 
>     
> 
>     
> 
>   
> 
>

On 05/12/2016 12:23 PM, lejeczek wrote:
> On Fri, 2016-05-06 at 07:41 -0400, Laine Stump wrote:
>> On 05/04/2016 08:40 AM, lejeczek wrote:
>>> hi users
>>>
>>> I have my dhcpd to serve nothing but virbr0 (libvirt), OS is Centos
7.2
>>> Dhcpd would not start, complaining like this:
>>> No subnet declaration for virbr0 (no IPv4 addresses).
>>> ** Ignoring requests on virbr0.  If this is not what
>>>    you want, please write a subnet declaration
>>>    in your dhcpd.conf file for the network segment
>>>    to which interface virbr0 is attached. **
>>>
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!)

>>
>> 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?)
> yes, set up like this:
>  <forward mode='route'/>
>   <bridge name='virbr0' stp='on' delay='0'/>
>
> It really is simple plain vanilla setup, maybe not common but simple, 
> should be easy to reproduce: libvirtd's only one virbr0 and dhcpd to 
> listen only on this iface.
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).

>
>>
>>>
>>> No subnet declaration for virbr0 (no IPv4 addresses).
>>> ** Ignoring requests on virbr0.  If this is not what
>>>    you want, please write a subnet declaration
>>>    in your dhcpd.conf file for the network segment
>>>    to which interface virbr0 is attached. **
>>>
>>> and systemctl -l shows:
>>> ...
>>> systemd[1]: start request repeated too quickly for dhcpd.service
>>> ...
>>>
>>> but suffice to restart dhcpd and all works!
>>> I'v customized systemd's service conf, I've put:
>>>
>>> After=libvirtd.service
>>> Requisite=libvirtd.service
>>
>> 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.
>>
>>>
>>> but this did not help.
>>> Would you share your thoughts? Systemd list say it's libvirt 
>>> (wrong)doing.
>>> many thanks.
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 Thu, 2016-05-12 at 13:10 -0400, Laine Stump wrote:
> On 05/12/2016 12:23 PM, lejeczek wrote:
> > On Fri, 2016-05-06 at 07:41 -0400, Laine Stump wrote:
> > > On 05/04/2016 08:40 AM, lejeczek wrote:
> > > > hi users
> > > > 
> > > > I have my dhcpd to serve nothing but virbr0 (libvirt), OS is
> > > > Centos 7.2
> > > > Dhcpd would not start, complaining like this:
> > > > No subnet declaration for virbr0 (no IPv4 addresses).
> > > > ** Ignoring requests on virbr0.  If this is not what
> > > >    you want, please write a subnet declaration
> > > >    in your dhcpd.conf file for the network segment
> > > >    to which interface virbr0 is attached. **
> > > > 
> 
> 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  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!)
> 
> 
> > > 
> > > 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?)
> > yes, set up like this:
> >  <forward mode='route'/>
> >   <bridge name='virbr0' stp='on'
delay='0'/>
> > 
> > It really is simple plain vanilla setup, maybe not common but
> > simple, 
> > should be easy to reproduce: libvirtd's only one virbr0 and dhcpd
> > to 
> > listen only on this iface.
> 
> Ah right, since there is no  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  element, " 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).
> 
> 
nonsensical is a good word, I'm guessing that your are assuming I'm
tampering with it in all possible weird ways, which would be, yes,
nonsensical.
Of course there is an IP attached to this configuration, like I said
already it's pretty plain vanilla setup, should be very easy to
reproduce for anybody, for you too.
Use Centos (probably any RHEL derivative) and have one virtbr like
this:
<network>
  <name>default</name>
  <uuid>894300f8-ecb4-4bac-8d1f-db3872d87435</uuid>
  <forward mode='route'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:e6:14:c9'/>
  <ip address='10.5.10.17' netmask='255.255.255.240'>
  </ip>
</network>
above subnet is completely separate & different from any other host's
ifaces.
in your systemd's dhcpd service config:
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd
-group dhcpd --no-pid virbr0
have your dhcpd.conf constructed to serve that virbr0 and the subnet,
and... that is it. See if your dhcpd starts @bootime?
> > 
> > 
> > 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > No subnet declaration for virbr0 (no IPv4 addresses).
> > > > ** Ignoring requests on virbr0.  If this is not what
> > > >    you want, please write a subnet declaration
> > > >    in your dhcpd.conf file for the network segment
> > > >    to which interface virbr0 is attached. **
> > > > 
> > > > and systemctl -l shows:
> > > > ...
> > > > systemd[1]: start request repeated too quickly for
dhcpd.service
> > > > ...
> > > > 
> > > > but suffice to restart dhcpd and all works!
> > > > I'v customized systemd's service conf, I've put:
> > > > 
> > > > After=libvirtd.service
> > > > Requisite=libvirtd.service
> > > > 
> > > 
> > > 
> > > 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.
> > > 
> > > 
> > > > 
> > > > 
> > > > but this did not help.
> > > > Would you share your thoughts? Systemd list say it's
libvirt
> > > > (wrong)doing.
> > > > many thanks.
> > > > 
> > > 
> > 
> 
> 
> 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  
> .... ...") then change the network definition 
> like this:
> 
> 
>      
>          mynet
>          
>          
>      
> 
> 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.
>