[libvirt] [PATCHv3 1/2] network: added waiting for DAD to finish for bridge address.
mperevedentsev at virtuozzo.com
Mon Oct 19 12:36:16 UTC 2015
On 10/16/2015 08:13 PM, Laine Stump wrote:
> On 10/16/2015 12:51 PM, Maxim Perevedentsev wrote:
>> On 10/15/2015 09:03 PM, Laine Stump wrote:
>>> This loop *really* bothers me, because there is no failsafe to
>>> terminate it if we never get positive notification that DAD has
>>> completed. This would lock up the network driver startup, which
>>> would lock up libvirtd startup. I think we need to decide on what is
>>> the maximum time this could possibly take to complete (maybe it is
>>> somehow based on the number of interfaces? or maybe it doesn't
>>> matter...) and timeout from the loop after the appropriate iterations.
>> I did not hear about general timeout for this operation. Maybe 5 min,
>> for example?
> 5 minutes is a very long time when everything else is being held up.
> If the wait for each network is much beyond a couple seconds, we'll
> need to think about spawning off a thread to wait for DAD.
> (if you're curious where the single-threadedness is, look at
> virStateInitialize() - it calls the stateAutoStart() function for each
> subsystem driver in sequence, and within the stateAutoStart() for the
> network driver, each network with autostart set is called in sequence).
I looked at kernel sources. It looks like DAD time is configurable:
rand() % net.ipv6.conf.default.router_solicitation_delay [1s] +
net.ipv6.conf.default.dad_transmits  *
By default on my machine, it gives 0s + 1 * 1000ms = 1s maximum.
Kernel keeps track of DAD success (on timeout) / fail. We could take
these variables from sysctl, but this is cumbersome. I suggest taking 5s
as maximum timeout and hope this is not too long.
Yes, I *really* do not want to write this thread-related stuff :)
>>> Is the "ip" command available on non-linux platforms? I know there
>>> is *a lot* of netlink stuff in there). Aside from that, POSIX_SHELL
>>> isn't even defined, so this code would fail to compile on non-Linux
>>> platforms with IP_PATH defined (and it would fail to compile on
>>> non-Linux with IP_PATH *not* defined, since addrs and count would
>>> then need ATTRIBUTE_UNUSED). Anyway we try to avoid execing external
>>> binaries unless absolutely necessary, so I think it's reasonable to
>>> only have a stub function that says "not supported" in place of this
>>> (very polite but non-working) replacement.
>> Ok. I wanted to work-around the case if we do not have libnl installed.
> There are other things that will fail if libnl isn't installed. Are
> you actually building libvirt without libnl enabled and having any
> amount of success? (since the only way we interact with netlink is via
> libnl, anything that requires netlink will not work, e.g. macvtap
No, I don't. Thank you for explanation.
More information about the libvir-list