[libvirt] Fwd: libvirtd and listen_addr

[Daniel P. Berrange]

On Thu, Jan 06, 2011 at 06:00:24PM +0100, Daniel Huhardeaux wrote:
> Le 06/01/2011 17:24, Justin Clift a écrit :
> >On 06/01/2011, at 8:26 PM, Daniel Huhardeaux wrote:
> >>Hello,
> >>
> >>got no reaction on this, I try again :-)
> >
> >Hmmm, just thought of a workaround if it helps. :)
> >
> >You already know that when libvirtd starts, it automatically starts the virtual networks that it has been told to.
> >
> >But, if you then shut libvirtd down, they're left running.
> >
> >So... my thought of a dodgy workaround is this... after libvirtd starts... and the virtual networks have started... restart libvirtd.
> >
> >I *think* that would then let libvirt bind to the new ip addresses.
> >
> >Reckon it's worth trying?
> 
> That's how I discover the problem ;-)
> 
> Everything was running fine until ... I had to reboot the server!
> VMs are started automatically but libvirtd will not start.
> 
> In your doggy workaround ;-) libvirtd will NOT start because of the
> missing listen_addr.
> 
> That's why I was thinking that libvirt start networks *before* it
> take care of listen_addr or perhaps listen_addr shouldn't cancel the
> start of libvirt (delay it) until network is up and then check if
> listen_addr is in error or not.

In general this approach isn't going to work. In the very near
future, libvirt itself won't be listen()ing on sockets itself.
Instead SystemD will do the listening and pass the pre-opened
server socket to libvirt at startup time.

In addition, we delibrately listen on all sockets very early
in startup, so that libvirtd can go into the background quickly.
This lets system bootup continue without delays, while the
potentially very slow auto-startup of VMs, networks, etc is
done in the background by libvirtd. The key is that by listen()
on the sockets immediately, but not accept()ing connections
until autostart is complete, clients like virsh can immediately
connect to libvirt and block on autostart. We can't reverse the
startup order as you suggest without breaking this key feature.

An alternative approach without the chicken & egg problem is
to listen on all addresses, and use the firewall to restrict
where you can connect from.

Regards,
Daniel