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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list