[libvirt] Fwd: libvirtd and listen_addr

[Daniel P. Berrange]

On Thu, Jan 06, 2011 at 05:13:41PM +0000, Daniel P. Berrange wrote:
> 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.

Or make libvirtd listen on 127.0.0.1, and then use iptables
to setup a local port forwarding from 10.0.0.1 to 127.0.0.1
on the libvirt port(s).

Daniel