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

[Daniel P. Berrange]

On Thu, Jun 18, 2009 at 05:53:59PM +0000, David Lutterkort wrote:
> On Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote:
> > On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote:
> >
> > >    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.
> 
> That only makes sense when reading an existing config, with the meaning
> 'the interface uses DHCP when it is brought up, and has the following
> address currently assigned to it'; it makes no sense when using the XML
> to configure a device.
> 
> I would prefer for that case a separate API call to ask for currently
> assigned addresses.
> 
> > 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
> 
> You can achieve the same by making interface-addressing optional where
> it is used.
> 
> > Check out this preso for an overview if you dare.
> > 
> >   http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf
> 
> Need to read that first.
> 
> > 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
> 
> The valid range for prefix-pattern differs, and we should therefore
> between the two.
> 
> > 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
> 
> I don't think that's the right notation, don't you mean 'eth1.42 -> br2'
> etc. ?
> 
> > 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
> 
> For that, you'd nest them where they are used, e.g. one connection to
> establish the base ethernet interface (that might not exist at all):
> 
>         <interface type="ethernet" startmode="none">
>           <name>eth0</name>
>           <mtu size="1492"/>
>           <mac address="aa:bb:cc:dd:ee:ff"/>
>           <dhcp peerdns="no"/>
>         </interface>
>         
> and one for the bridge with a vlan enslaved:
> 
>         <interface type="bridge" startmode="onboot">
>           <name>br0</name>
>           ...
>           <bridge stp="off">
>             <interface type="vlan" device="eth0" tag="42"/>
>           </bridge>
>         </interface>
> 
> Similarly, a bond enslaved to a bridge, together with a vlan on that
> bond also enslaved to the bridge would look like
> 
>         <interface type="bridge" startmode="onboot">
>           <name>br0</name>
>           ...
>           <bridge stp="off">
>             <interface type="bond">
>               <name>bond0</name>
>               <bond mode="active-backup">
>                 <interface type="ethernet">
>                   <name>eth1</name>
>                 </interface>
>                 <interface type="ethernet">
>                   <name>eth0</name>
>                 </interface>
>               </bond>
>             </interface>
>             <interface type="vlan" device="bond0" tag="42"/>
>           </bridge>
>         </interface>

I think this is a really unpleasant format to deal with. IMHO there should
not be  nesting for <bridge>/<bond> tags. They should just refer to their
slave device by name. So that last example would be better shown as a set
of independant intefaces

         <interface type='bond'>
           <name>bond0</name>
           <bond mode="active-backup">
             <interface name='eth0'/>
             <interface name='eth1'/>
           </bond>
         </interface>

         <interface type='vlan'>
           <name>bond0.42</name>
           <vlan tag='42'>
            <interface name='bond0'>
           </bridge>
         </interface>

         <interface type="bridge" startmode="onboot">
           <name>br0</name>
           ...
           <bridge stp="off">
             <interface name="bond0.42"/>
           </bridge>
         <interface>

If you added more vlans, then they just appear as more interfaces at
the top level

         <interface type='vlan'>
           <name>bond0.47</name>
           <vlan tag='47'>
            <interface name='bond0'>
           </bridge>
         </interface>

         <interface type='vlan'>
           <name>bond0.48</name>
           <vlan tag='48'>
            <interface name='bond0'>
           </bridge>
         </interface>



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