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?

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).

Hmmm, in your libvirtd.conf file, what does the line say where you have "listen_addr"? I'm thinking it should be something like: listen_addr = "0.0.0.0" Which I *think* tells it to bind to everything it can. ?

On 07/01/2011, at 4:39 AM, Daniel Huhardeaux wrote: > Le 06/01/2011 18:16, Justin Clift a écrit : > > [...] > >> Hmmm, in your libvirtd.conf file, what does the line say where you have "listen_addr"? >> >> I'm thinking it should be something like: >> >> listen_addr = "0.0.0.0" >> >> Which I *think* tells it to bind to everything it can. >> >> ? > > Yes but that's not what I want. Let's say we have 3 servers each of them with VMs and all connected through OpenVPN > > server 1: VMs Net 10.0.1.1 (IP of server virbr0) VMs from .1.11 to ... > server 2: VMs Net 10.0.2.1 (IP of server virbr0) VMs from .2.11 to ... > server 3: VMs Net 10.0.3.1 (IP of server virbr0) VMs from .3.11 to ... > > Having OpenVPN running, each VM -or other host running OpenVPN- can reach each other. So what I want, for security reason, is that listen_addr of each server is *only* 10.0.[1|2|3].1 which is transparent and independant of other network settings (public addresses, localnet, other VPN, ...). > > Hope I clarify my needs :-) Heh, yeah. I think Daniel Berrange's approach of using firewall rules to control the access is probably the most rugged...