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...
Also, US $5 to anybody who knows whether the<route/> tag above
says 'is configured to use that gateway' or 'routing is through that
gateway right now'.
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)
The live XML should *always* say what the inteface is doing right
now.
Up to the point that is possible, that's my intent.
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".
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...)
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.)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
