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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 05, 2009 at 12:18:33PM -0400, Laine Stump wrote:
> On 10/05/2009 07:02 AM, Daniel P. Berrange wrote:
> >On Tue, Sep 29, 2009 at 04:02:30PM -0400, Laine Stump wrote:
> >   
> >>From: root<root@xxxxxxxxxxxxxx>
> >>
> >>This patch adds the flag VIR_INTERFACE_XML_INACTIVE to
> >>virInterfaceGetXMLDesc's flags. When it is *not* set (the default),
> >>the live interface info will be returned in the XML. in particular,
> >>the IP address(es) and netmask(s) will be retrieved by querying the
> >>device directly, rather than just reporting what's in the config
> >>file. The backend of this is in netcf's new ncf_if_xml_state()
> >>function.
> >>
> >>Any live interface ip address info in the xml will have the property
> >>"source" set to "device", eg:
> >>
> >>          <ip address='10.24.0.1' prefix='24' source='device'/>
> >>     
> >This new 'source' attribute is bogus. The fact that the XML is the
> >showing the device details, and not the config file details is
> >inherent in the fact that we're querying the live interface. This
> >distinction applies to the entire XML dump, not just the<ip>  tag.
> >   
> 
> The 'source' attribute came out of the exchange at the bottom of these 
> messages:
> 
> https://fedorahosted.org/pipermail/netcf-devel/2009-September/000258.html
> https://fedorahosted.org/pipermail/netcf-devel/2009-September/000259.html
> https://fedorahosted.org/pipermail/netcf-devel/2009-September/000260.html
> 
> (I included all the messages in case too much context was removed in the 
> replies).
> 
> Some/most of the stuff in the XML still comes from the config files even 
> though we're querying the "live interface', because some info isn't 
> available reliably in any other way (for example, it's useful to know 
> that dhcp is setup for the interface, but I don't believe there's any 
> way to query dhclient to see if that truly is the case). The idea was to 
> put some sort of tag on the particular items that were really coming 
> from the device. I will say that, if nothing else, having this extra 
> attribute has mmade it easier for me to verify that my patches are 
> actually doing something ;-) In the end, I looked at it kindly  because 
> it didn't seem to hurt anything (most people just ignore extra stuff in 
> the xml), and might help someone.

I'm not really convinced by that thread. If the virInterfaceDumpXML
API only ever exposed the live XML config, then there' would be a 
compelling need to identify whether the <ip> info were from the DHCP
or the persistent config. The whole point of having the extra 
VIR_INTERFACE_XML_INACIVE  flag though, is to allow the caller to
access the full persistent XML config, independantly of the live XML
config. This is much more powerful because they can compare every 
aspect of the XML description, not merely that one element. 

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. Eventually we introduced the extra
VIR_DOMAIN_XML_INACTIVE flag to allow the full distinction/comparison
to be made, rather than doing lots of small hacks in the XML each
time we case across a new special case. I'd really like us to avoid
making this mistake again in the interface XML, and just use the
VIR_INTERFACE_XML_INACTIVE flag for this scenario.

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 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]