[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
Daniel Veillard
veillard at redhat.com
Thu Jun 18 14:06:40 UTC 2009
On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote:
> On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote:
> > On Wed, 2009-06-17 at 21:32 +0100, Daniel P. Berrange wrote:
> > > How do you deal with IPv6 currently ?
> >
> > With lots of Aspirin (actually, not at all)
Very very very slowly ... I remember in 96 IETF meetings the
propaganda that we were doomed if we didn't switch *right now* >:->
I also saw major brands of routers failing in faily nefastous ways
when anxious people activated IPv6 a bit before everybody else.
But jokes apart we need to have this working now ...
> > > I was thinking of sugesting an attribute
> > >
> > > <ip type="ipv6" address="2001:23::2" prefix="24"/>
> > >
> > > but I think its possibly better to have a different element name
> > >
> > > <ip6 address="2001:23::2" prefix="24"/>
> > >
> > > since the former would not work if we ever needed to worry about
> > > non-IP based addresses.
> >
> > Either works for me, with a slight preference for the first version, on
> > purely esthetic grounds. And even if we go with that, there's nothing
> > keeping us from adding an <ipx> element as an alternative to the <ip>
> > element in the future.
>
> Or a 3rd option is to group addresses by family
>
>
> <addresses family='ipv4'>
> <ip address='122.0.0.3' prefix='24'/>
> <ip address='24.24.224.4' prefix='24'/>
> </addresses>
> <addresses family='ipv6'>
> <ip address='2001:23::2' prefix='48'/>
> <ip address='fe:33:55::33' prefix='64'/>
> </addresses>
> <adddresses family='ipx'>
> <ipx address='2423.4521.66.3.252.'/>
> </address>
Hum, right now the syntax is far more restrictive for addressing,
there is one address, period, with an optional route we need to extend
that IMHO.
[...]
The problem with the propsal is that it opens the door to a variety of
errors like using the same familly twice, which I would like to avoid
at the RNG level but it's not trivial.
We should allow standalone IPv4 and IPv6, or both. Each could either
use DHCP or allow one or more IP address and routes.
I think if we have routes, at most one need to be a gateway and the
other ones having destination + prefix.
So I suggest the following rewrite of interface-addressing
<!-- Assignment of IP address to an interface -->
<define name="interface-addressing">
<choice>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
<group>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
</group>
</choice>
</define>
This allows one or 2 blocks of addresses ipv4, ipv6 or both
<define name="interface-addr-ipv4">
<element name="addresses">
<attribute name="family">
<value>ipv4</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
An IPv4 addresses block, allows for either static or dhcp
<define name="interface-addr-ipv6">
<element name="addresses">
<attribute name="family">
<value>ipv6</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
same for IPv6
<define name="interface-addr-static">
<oneOrMore>
<element name="ip">
<attribute name="address"><ref name="ip-addr"/></attribute>
<attribute name="prefix"><ref name="prefix-pattern"/></attribute>
</element>
</oneOrMore>
<optional>
<ref name="interface-addr-routes"/>
</optional>
</define>
A static addressing scheme is made of one or more <ip> elements with
address and prefix followed by optional routing info
<define name="interface-addr-dhcp">
<element name="dhcp">
<optional>
<attribute name="peerdns">
<ref name="yes-or-no"/>
</attribute>
</optional>
</element>
</define>
For DHCP the only option is the peerdns yes/no attribute
<define name="interface-addr-routes">
<element name="route">
<attribute name="destination">
<value>default</value>
</attribute>
<attribute name="gateway"><ref name="ip-addr"/></attribute>
</element>
<zeroOrMore>
<element name="route">
<attribute name="destination"><ref name="ip-addr"/></attribute>
<attribute name="prefix"><ref name="prefix-pattern"/></attribute>
<optional>
<attribute name="gateway"><ref name="ip-addr"/></attribute>
</optional>
</element>
</zeroOrMore>
</define>
And for routes we have at least one default route and
then an optional set of routes with prefixes and optional gateways for
that device. To note all the ip/dhcp/route constructs are similar for
IPv4 and IPv6 as we don't check content precisely here. I assume it's
sufficient.
I think this revamps the capabilities quite a bit but I guess it
should make sure we have IPv6 support on equal footing, and also
incorporates I think most of Jim Fehlig remaks noted in the RNG.
Examples of working definitions:
<interface type="ethernet" startmode="onboot">
<name>eth1</name>
<mtu size="1500"/>
<mac address="00:1A:A0:8F:39:A6"/>
<addresses family='ipv4'>
<dhcp peerdns="no"/>
</addresses>
</interface>
<interface type="ethernet" startmode="none">
<name>eth2</name>
<addresses family='ipv4'>
<dhcp/>
</addresses>
<addresses family='ipv6'>
<dhcp/>
</addresses>
</interface>
<interface type="ethernet" startmode="hotplug">
<name>eth3</name>
<mac address="00:1A:A0:8F:50:B7"/>
<addresses family='ipv4'>
<ip address="192.168.0.15" prefix="24"/>
<ip address="192.168.1.10" prefix="24"/>
<route destination="default" gateway="192.168.0.1"/>
<route destination="192.168.1.0" prefix="24" gateway="192.168.1.1"/>
</addresses>
</interface>
This makes parsing a bit heavier, and I didn't checked if this really
affected bridging and bonding interfaces in a wrong way, but I think
that at least at an ethernet level definition this looks more complete.
That said I have no idea how much of a problem it would be on the netcf
impletmentation side.
Daniel
P.S.: full rng attached, double check the prefix-pattern definition
I have no idea if it's sufficient for Ipv6
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
-------------- next part --------------
<!-- A Relax NG schema for network interfaces -->
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<choice>
<ref name="ethernet-interface"/>
<ref name="bridge-interface"/>
<ref name="bond-interface"/>
</choice>
</start>
<!--
FIXME: How do we handle VLAN's ? Should they be their own interface
or should we treat them as an option on the base interface ? For
example, for vlan eth0.42, it would make sense to make that part of
the definition of the eth0 interface.
-->
<!--
Ethernet adapter
-->
<define name="basic-ethernet-content">
<attribute name="type">
<value>ethernet</value>
</attribute>
<ref name="basic-attrs"/>
<!-- If no MAC is given when the interface is defined, it is determined
by using the device name.
FIXME: What if device name and MAC don't specify the same NIC ? -->
<optional>
<element name="mac">
<attribute name="address"><ref name="mac-addr"/></attribute>
</element>
</optional>
<!-- FIXME: Allow (some) ethtool options -->
</define>
<!-- Ethernet adapter without IP addressing, e.g. for a bridge -->
<define name="bare-ethernet-interface">
<element name="interface">
<ref name="basic-ethernet-content"/>
</element>
</define>
<define name="ethernet-interface">
<element name="interface">
<ref name="startmode"/>
<ref name="basic-ethernet-content"/>
<ref name="interface-addressing"/>
</element>
</define>
<!--
Bridges
-->
<define name="bridge-interface">
<element name="interface">
<attribute name="type">
<value>bridge</value>
</attribute>
<ref name="startmode"/>
<ref name="basic-attrs"/>
<ref name="interface-addressing"/>
<element name="bridge">
<optional>
<attribute name="stp">
<ref name="on-or-off"/>
</attribute>
</optional>
<oneOrMore>
<ref name="bare-ethernet-interface"/>
</oneOrMore>
</element>
</element>
</define>
<!-- Jim Fehlig would like support for other bridge attributes, in
particular hellotime, forwarddelay, and maxage
-->
<!--
Bonds
-->
<define name="bond-interface">
<element name="interface">
<attribute name="type">
<value>bond</value>
</attribute>
<ref name="startmode"/>
<ref name="basic-attrs"/>
<ref name="interface-addressing"/>
<element name="bond">
<optional>
<attribute name="mode">
<choice>
<value>balance-rr</value>
<!-- The primary interface is the first interface child
of the bond element -->
<value>active-backup</value>
<value>balance-xor</value>
<value>broadcast</value>
<value>802.3ad</value>
<value>balance-tlb</value>
<value>balance-alb</value>
</choice>
</attribute>
</optional>
<oneOrMore>
<!-- The slave interfaces -->
<ref name="bare-ethernet-interface"/>
</oneOrMore>
</element>
</element>
</define>
<!-- Basic attributes for all interface types -->
<define name="basic-attrs">
<!-- The device name, like eth0 or br2 -->
<element name="name"><ref name="device-name"/></element>
<optional>
<element name="mtu">
<attribute name="size"><ref name="unsigned-int"/></attribute>
</element>
</optional>
</define>
<define name="startmode">
<attribute name="startmode">
<choice>
<value>onboot</value>
<value>none</value>
<value>hotplug</value>
<!-- Jim Fehlig lists the following that SuSe supports:
manual, ifplug, nfsroot -->
</choice>
</attribute>
</define>
<!-- Assignment of IP address to an interface -->
<define name="interface-addressing">
<choice>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
<group>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
</group>
</choice>
</define>
<define name="interface-addr-ipv4">
<element name="addresses">
<attribute name="family">
<value>ipv4</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
<define name="interface-addr-ipv6">
<element name="addresses">
<attribute name="family">
<value>ipv6</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
<define name="interface-addr-static">
<oneOrMore>
<element name="ip">
<attribute name="address"><ref name="ip-addr"/></attribute>
<attribute name="prefix"><ref name="prefix-pattern"/></attribute>
</element>
</oneOrMore>
<optional>
<ref name="interface-addr-routes"/>
</optional>
</define>
<define name="interface-addr-dhcp">
<element name="dhcp">
<optional>
<attribute name="peerdns">
<ref name="yes-or-no"/>
</attribute>
</optional>
</element>
</define>
<define name="interface-addr-routes">
<element name="route">
<attribute name="destination">
<value>default</value>
</attribute>
<attribute name="gateway"><ref name="ip-addr"/></attribute>
</element>
<zeroOrMore>
<element name="route">
<attribute name="destination"><ref name="ip-addr"/></attribute>
<attribute name="prefix"><ref name="prefix-pattern"/></attribute>
<optional>
<attribute name="gateway"><ref name="ip-addr"/></attribute>
</optional>
</element>
</zeroOrMore>
</define>
<!-- Jim Fehlig (<jfehlig at novell.com>) suggest the
following additions to DHCP:
WRT dhcp element, would it make sense to consider hostname (hostname
to send to server) and if to change the local hostname to the
hostname delivered via dhcp? E.g. hostname="foo" (default
`hostname`) sethostname
Also route:
setrouting (default "yes")
setdefaultroute (default "yes")
and NIS:
nis (default "yes")
setnisdomain (default "yes")
What about dhcpv6? A separate <dhcp6 /> element?
-->
<!-- Jim Fehlig suggest adding static routing info
As for routing info, how about a separate route element:
<route gateway="192.168.0.1" /> # destination=default
<route destination="default" gateway="192.168.0.1" />
<route destination="10.0.0.0/8" gateway="192.168.0.2" />
<route destination="2001:DB8:C::/64" gateway="2001:DB8:C::1" />
<route destination="2001:DB8::/32"> # unrecheable route (loopback)
It would perhaps make sense to use iproute2 names, that is prefix
instead of destination and nexthop instead of gateway.
-->
<!-- Auxiliary definitions -->
<define name="on-or-off">
<choice>
<value>on</value>
<value>off</value>
</choice>
</define>
<define name="yes-or-no">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</define>
<!-- Type library -->
<define name='unsigned-int'>
<data type='unsignedInt'>
<param name="pattern">[0-9]+</param>
</data>
</define>
<define name='device-name'>
<data type='string'>
<param name="pattern">[a-zA-Z0-9_\.\-:/]+</param>
</data>
</define>
<define name='UUID'>
<choice>
<data type='string'>
<param name="pattern">[a-fA-F0-9]{32}</param>
</data>
<data type='string'>
<param name="pattern">[a-fA-F0-9]{8}\-([a-fA-F0-9]{4}\-){3}[a-fA-F0-9]{12}</param>
</data>
</choice>
</define>
<define name='mac-addr'>
<data type='string'>
<param name="pattern">([a-fA-F0-9]{2}:){5}[a-fA-F0-9]{2}</param>
</data>
</define>
<define name='ip-addr'>
<data type='string'>
<param name="pattern">([0-2]?[0-9]?[0-9]\.){3}[0-2]?[0-9]?[0-9]</param>
</data>
</define>
<define name='ip-mask'>
<data type='string'>
<param name="pattern">([0-2]?[0-9]?[0-9]\.){3}[0-2]?[0-9]?[0-9](/[0-9][0-9]?)?</param>
</data>
</define>
<define name='prefix-pattern'>
<data type='string'>
<param name="pattern">[0-9][0-9]?</param>
</data>
</define>
</grammar>
More information about the libvir-list
mailing list