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

Tue Oct 6 14:13:46 UTC 2009

On Tue, Oct 06, 2009 at 09:55:06AM -0400, Laine Stump wrote:
> On 10/06/2009 05:13 AM, Daniel P. Berrange wrote:
> >On Mon, Oct 05, 2009 at 02:34:05PM -0700, David Lutterkort wrote:
> >   
> >>On Mon, 2009-10-05 at 17:34 +0100, Daniel P. Berrange wrote:
> >>     
> >>>With the domain XML format, we did have a few abortive attempts at
> >>>indicating in the live XML, whether an attribute was from the
> >>>persistent config, vs dynamically added to live config, but it all
> >>>ended up as rather a mess.
> >>>       
> >>Here's a concrete example where this leads to headscratching, at a
> >>minimum, with the netowrk configs. When the live XML contains
> >>
> >>         <protocol family="ipv4">
> >>           <dhcp/>
> >>           <ip address="192.168.0.5" prefix="24"/>
> >>           <route gateway="192.168.0.1"/>
> >>         </protocol>
> >>
> >>you at least think that the interface is configured to use DHCP, and
> >>currently has the indicated address. Of course, if we ever poke around
> >>to see if the interface _currently_ gets its address from DHCP, we have
> >>no way to indicate that anymore, since we would indicate 'configured to
> >>use DHCP' and 'currently gets its address from DHCP' in exactly the same
> >>way.
> 
> 
> 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...

I don't think it is important where the address on a interface
came from. As you say it is essentially impossible to determine tha
after the fact, so its not worth trying to figure that out. Apps
that really care that much would be fully managing networrking on
the OS so likely already know where the addresses are coming from
The libvirt interface XML should just focus on what's present, not
where it came from.

> >The live XML should *always* say what the inteface is doing right
> >now.
> 
> Up to the point that is possible, that's my intent.

If you restrict scope to reporting what is currently present,
and not worry about where they came from, it should be pretty
straightforward, after all, it is just presenting the same
info as ifconfig / ip  commands would in that scenario

> >>To belabor this point, when the live XML says
> >>
> >>         <protocol family="ipv4">
> >>           <ip address="192.168.0.5" prefix="24"/>
> >>           <ip address="192.168.0.6" prefix="24"/>
> >>         </protocol>
> >>
> >>it's completely unclear what addresses are in the config files (maybe
> >>both?) and which ones are actually assigned to the interface right now.
> >>     
> >I think there is a disconnect here about the behaviour we should
> >be exposing.  In that example of live XML above with 2 IP addresses,
> >both of those IP address *must* be currently assigned to the interface,
> >since this is the live XML.  To determine which (if any) of those
> >addresses are in the config file, the VIR_INTEFACE_XML_INACTIVE flag
> >would be used.
> >   
> 
> 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".

[snip]

> >Looking at netcf, it does not appear to implement this correctly. If
> >I query the live XML of an interface, it gives back a mixture of
> >both the config file and active addresses. Indeed, if using a static
> >IP address, it'll list the same IP address twice in the XML once it
> >pulls it from the config file, and once from the interface.
> >   
> 
> 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.)

Ah, so that's not in the netcf  0.12  release then ?  That's what I've
been testing this stuff with & seeing the behaviour of mixed config and
live addresses

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|