Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces

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