[libvirt] [PATCH 13/13] Run radvd for virtual networks with IPv6 addresses

Laine Stump laine at laine.org
Wed Dec 22 18:01:31 UTC 2010


On 12/20/2010 05:46 PM, Paweł Krześniak wrote:
> On Mon, Dec 20, 2010 at 09:03, Laine Stump<laine at laine.org>  wrote:
>> There are two possible solutions for this:
>>
>> 1) Don't attempt to immediately read the pidfile and store the pid in
>>    memory. Instead, just read the pidfile later when we want to kill
>>    radvd. (This could still lead to a race if networkStart and
>>    networkDestroy were called in tight sequence by some application)
> In such tight sequence you can detect that radvd has been just
> started, because radvd truncates pidfile before daemon(). In such
> situation you can wait for pid awhile (e.g. separate thread could use
> inotify for this)

It works out reasonably well to manually daemonize radvd, and create the 
pidfile ourselves, so that's the way I'm doing it.

> Some general questions:
> - radvd is optional for ipv6 network. How one can configure to not to
> spawn radvd daemon

We decided back when we were discussing this feature that we wanted 
radvd to always be run. The logic is that we want the virtual networks 
to cover the needs of 95% of installations, and be as simple as possible 
for all of those. The other 5% will need to setup their bridge manually. 
(Keep in mind that even when radvd is running, it's totally acceptable 
for a guest to ignore it and manually configure their interfaces, so 
even most people who don't want/need radvd can live with its presence).

Here's the original discussion thread:

https://www.redhat.com/archives/libvir-list/2010-November/msg00146.html

> - did you thought about running only one instance of radvd and sending
> SIGHUP to daemon after adding/removing interfaces to conffile

Yes, we talked about that as well, and decided that we wanted libvirt's 
use of radvd to be as segregated from the rest of the system's use as 
possible - less potential for a problem in one place to leak over into 
another, and no headaches trying to cleanly/atomically edit the config file.




More information about the libvir-list mailing list