[libvirt] [PATCHv3 1/2] network: added waiting for DAD to finish for bridge address.

[Laine Stump]

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


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

>> Once these 3 issues are dealt with, I think we can (finally) push this.
> I'll try to fix it ASAP. Thank you.
>