[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
Thu Jun 18 17:06:27 UTC 2009


On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote:
> On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote:
> 
> > > > 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.

You need to have allow for IP adddresses & routes to be present even
when doing DHCP, because you need to discover what was auto-configured.

>    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

This is overly strict, because it does not allow for an interface
without any addresses - something you want todo if configuring a 
bridge device just for guest traffic and do not want any IP on it
for the host. So just need to make both optional

  <define name="interface-addressing">
    <group>
      <optional>
        <ref name="interface-addr-ipv4"/>
      <optional>
      <optional>
        <ref name="interface-addr-ipv6"/>
      <optional>
    </group>
  </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>
> 
> 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

Not quite - IPv6 needs to allow for more options

 - static                   - fully manual setup
 - autoconf                 - auto assign addresses/routes. Assume DNS etc via dhcpv4 or manual
 - autoconf + statless dhcp - auto assign addresses/routes. DNS etc via dhcpv6
 - statefull dhcp           - everything via dhcpv6

Check out this preso for an overview if you dare.

  http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf

In all cases we need to include <ip> tags to show the manual, or
automatically configured addresses/routes.

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

The 'ip-addr' match rule will need separate rules for IPv4 vs IP6
addresses, since the former use '.' as a seprator, while the latter
use ':'.   The 'prefix-pattern' can be same, since its just a number

> 
> <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"/>
       ..... possible  <ip> tag(s) here if interface is active
>   </addresses>
> </interface>
> 
> <interface type="ethernet" startmode="none">
>   <name>eth2</name>
>   <addresses family='ipv4'>
>     <dhcp/>
>   </addresses>
>   <addresses family='ipv6'>
>     <dhcp/>

This also needs to indicate whether 'autoconf' is on vs off.
Probably just want an <autoconf/>  element for that with
any combo of '<dhcp/>' and '<autoconf/>' allowed, including
neither.

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

The prefix is fine. the ip address rule needs to allow ':' for IPv6.



> <!-- 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.
>   -->

VLANs are tricky, because you can define VLANs on a physical 
inteface or a bond interface, and you then may want to also
add a bridge on top of a VLAN, eg take 2 physical NICs, eth0
and eth1, here are some possible combes

 -  One NIC for storage, another for host mgmt, and put
    the guests all on VLANs

     eth0 -> br0        IP addr used for storage
     eth1 -> br1        IP addr used  for host mgmt
     eth1.42 -> br1.42  IP addr, used to talk to guests
     eth1.43 -> br1.43  No IP, guest traffic only
     eth1.44 -> br1.44  No IP, guest traffic only

 - Bonded NICs, used for everything

     eth0 + eth1 -> bond0 -> br0  IP addr used for all

 - Bonded NICs, and VLANs for guests

     eth0 + eth1 -> bond0  IP addr used for host admin+storage
     bond0.42 -> br0.42    IP addr, used to talk to guests
     bond0.43 -> br0.43    No IP, guest traffic only

 - Bonded NICs, and VLANs for host and for guests

     eth0 + eth1 -> bond0  No IP, not used directly.
     bond0.42              IP addr, Host mgmt traffic
     bond0.43 -> br0.43    No IP, guest traffic only


I think the currently approach of modelling bond, bridges and NICs
makes this a little hard, particularly if the netcf API only exposes
'connections' and not interfaces, because some of these setups are
not really connections, only building blocks for 'n' other connections


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