On 05/31/2012 10:23 AM, Chris Evich wrote: > On 05/30/2012 06:00 AM, Cleber Rosa wrote: >> First, let me see If I understand this correctly: somehow the >> combination of tcpdump + the network config/stack in an rhev-h/ovirt >> node takes about 1 hour to get an IP? >> >> This reminds me of something I thought a while ago, when we decided to >> go with the libvirt private bridge as the default network for the KVM >> test: the dnsmasq daemon, which answers the DHCP requests, can be easily >> queried for leases, which can resolve the MAC -> IP for guests. >> >> That way, we could drop the requirement and the way we use tcpdump, >> which IMHO is as a nice little hack that we could live without. >> > > Unfortunately/fortunately tcpdump will probably have to stay. With > physical device bridges, dnsmasq is not used, rather a more > centralized DHCP server is used. Also consider that libvirt (and > tests) can start/stop/migrate VMs on other hosts. So we do need a way > of listening for DHCP broadcasts when static addresses are not used.
That are certainly situations when it's not going to communicate with the DHCP server, but for the default scenario, which is using the libvirt bridge, it *should* be reliable to do so. I think I have to write the code to say with more confidence. > > Another possibly viable alternative is to monitor the hosts arp cache. > I'm not sure if it's part of the ipv4 standard or not, but hosts > generally issue a gratuitous arp when they bring up an interface. The > down-side here is nearly the same as tcpdump/dhcp in that some > bridge/switch setups may not pass the arp through to all hosts. The way I see it is that we could have a "graceful degradation" design, talking to the DHCP server if we can, and using some other techniques (such as tcpdump, host arp cache, nmap, etc) if necessary. > > So, as ugly as it is, I think the tcpdump solution is the best, simple > hack we have. > I agree completely: it's ugly and it's the best we *currently* have :) _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
