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