[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