Re: [libvirt] [PATCH] Support reporting live interface IP/netmask.

On 10/06/2009 05:13 AM, Daniel P. Berrange wrote: Well, it's actually problematic no matter what we do, because it's not easy to differentiate between an IP address on an interface that was put there by dhclient, and one that was put there manually (and might be replaced as soon as dhclient decide's it's time to renew its lease, or might stay there forever, if the dhclient process has died or been killed). We *could* parse dhclient.leases to find what dhclient believes to be the address, and compare it to what was returned from the ioctl, however my past experience with dhclient.leases was that there tended to be a lot of old leases in there, making it a real pain to find the correct lease. Maybe what we *really* need is an attribute in the 'state' XML to indicate where the currently in-use addresses originated, ie source='dhcp', source='static-config', source='manual', or whatever. I don't know how much success we'd have at getting these correct, though... Once I get all the address reporting correct, I'm going to see what I can do about reporting routes directly from the kernel, and once that is the case, it will always mean "routing is through that gateway right now". I don't think the current "route" node within the interface protocol will be adequate, though - for example, it has no destination/netmask, no metric, and no method to indicate if the route comes from a routing protocol, or is static. It's really only intended for setting up the default route. (Anyway, I don't know that the best way to report the current route table is by mixing it in with interface state - a separate API may be more appropriate) Up to the point that is possible, that's my intent. The summary of the two methods: 1) info about whether an address is the "live" address vs. from the config file is explicitly indicated by presence/absence of the "source='device'" attribute. 2) info about whether an address is the "live" address vs. from the config file is implied by which function was called / option flag was given. Of course in both cases, no config-derived addresses are returned in the XML (when the INACTIVE flag isn't set), so it is guaranteed that any addresses will be "live". I'm tending to lean towards (2) at the moment - having the extra attribute seems a bit redundant, as long as we guarantee that we're removing all the config-derived items before presentation. If we were going to try and combine both live and config-derived items in the same XML, I would vote for (1). (We actually had a short discussion about whether or not to mix live and config data on the netcf mailing list, but didn't get much participation...) This was a bug in the original patch, corrected by this set of patches: https://fedorahosted.org/pipermail/netcf-devel/2009-September/000280.html Once those patches are applied, only the IP (v4) addresses currently on the device are returned (IPv6 address reporting will work rsn.)