[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
Daniel P. Berrange
berrange at redhat.com
Wed Jun 17 20:35:13 UTC 2009
On Wed, Jun 17, 2009 at 10:33:02PM +0200, Daniel Veillard wrote:
> On Wed, Jun 17, 2009 at 01:27:14PM -0700, David Lutterkort wrote:
> > On Wed, 2009-06-17 at 22:10 +0200, Daniel Veillard wrote:
> > > On Wed, Jun 17, 2009 at 09:03:32PM +0100, Daniel P. Berrange wrote:
> > > > On Wed, Jun 17, 2009 at 09:42:11PM +0200, Daniel Veillard wrote:
> > > > > On Wed, Jun 17, 2009 at 12:22:13PM -0700, David Lutterkort wrote:
> > > > > > On Wed, 2009-06-17 at 19:24 +0100, Daniel P. Berrange wrote:
> > > > > > > IP address information should be in the XML, and indeed surely it is
> > > > > > > already there in order to allow non-DHCP based IP address config
> > > > > > > on interfaces ?
> > > > > >
> > > > > > Yes, for statically configured interfaces, the IP information is in the
> > > > > > XML - that is the _configured_ IP info though, not necessarily the one
> > > > > > that the interface actually uses. The two can diverge, for example, if
> > > > > > an interface is already up and then reconfigured.
> > > > >
> > > > > BTW I was looking at the Relax-NG grammar and found the following
> > > > > confusing when providing an IP address:
> > > > >
> > > > > <element name="ip">
> > > > > <optional>
> > > > > <attribute name="address"><ref name="ip-mask"/></attribute>
> > > > > </optional>
> > > > > </element>
> > > > >
> > > > > I'm not really sure what ip-mask really means, are you trying to
> > > > > put in a single attribute both the IP address and the netmask ?
> > > > > If that's the case I would really suggest to split the two as separated
> > > > > IP and netmask in the XML structure, either separate attributes or
> > > > > another element for the netmask. Best to us the explicit structure of
> > > > > XML than a construct hidden inside the text field, unless I
> > > > > misunderstood the use case...
> > > >
> > > > 'netmask' should really be avoided these days, in preference to 'prefix'
> > > > since the latter works for IPv4 and IPv6, while the former only works
> > > > for IPv4. 'netmask' can be auto-calculated from 'prefix' by apps if they
> > > > really care about it.
> > >
> > > Fine by me, just that I think they should be hold by 2 separate
> > > attributes or element if possible at this point.
> >
> > Yes, good point; and I don't know what I was thinking when I made the
> > address attribute optional.
> >
> > I'll change the schema to this:
> >
> > <element name="ip">
> > <attribute name="address"><ref name="ip-addr"/></attribute>
> > <attribute name="prefix"><ref name="prefix-pattern"/></attribute>
> > </element>
> >
> > so that you'll write
> >
> > <ip address="172.32.12.10" prefix="24"/>
>
> Cool :-)
>
> > I haven't declared the schema or the API stable yet, but I want to do
> > that once there is a libvirt release out there that relies on netcf. So
> > if there are any other issues with any of these aspects, raise them now
> > or forever hold your peace.
>
> Well I'm writing the parser, so sure I will raise those :-)
>
> There is also a lot of suggested extensions from Jim Fehlig, but I think
> they all can be handled as extension from the original schemas.
> One thing which needs to be ironed out IMHO is IPv6, better clean this
> up now than later. I'm not a IPv6 fan but making sure the schemas is ready
> for it is important I guess. The comment about <dhcp6 /> should probably be
> decided before first release.
Yeah we definitely need IPv6 stuff in the first of this since RHEL-5
and later are required to support IPv6 for every network service, and
I'm sure other enterprise distros have a similar requirement
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 :|
More information about the libvir-list
mailing list