More bonding parameters
by David Lutterkort
The current bonding support is missing a _lot_ of the bonding driver's
options, must crucially any sort of control over monitoring the bonded
devices.
This patch here is a rough sketch of how I intend to add that support to
the interface XML schema. I'd highly appreciate feedback from the
bonding experts on this list ;)
David
diff --git a/data/xml/interface.rng b/data/xml/interface.rng
index e07a9b0..a38dea5 100644
--- a/data/xml/interface.rng
+++ b/data/xml/interface.rng
@@ -104,6 +104,64 @@
</choice>
</attribute>
</optional>
+
+ <!-- FIXME: add more attributes
+
+ mode == 802.3ad
+ ad_select
+ lacp_rate
+ xmit_hash_policy
+
+ mode == active-backup
+ fail_over_mac
+ num_grat_arp when mode == active-backup (since 3.3.0)
+ num_unsol_na when mode == active-backup (ipv6, since 3.4.0)
+
+ mode == balance-xor
+ xmit_hash_policy (since 2.6.3/3.2.2)
+ -->
+
+ <choice>
+ <element name="miimon">
+ <!-- miimon frequency in ms -->
+ <attribute name="freq"><ref name="uint"/></attribute>
+ <optional>
+ <attribute name="downdelay"><ref name="uint"/></attribute>
+ </optional>
+ <optional>
+ <attribute name="updelay"><ref name="uint"/></attribute>
+ </optional>
+ <optional>
+ <!-- use_carrier -->
+ <attribute name="carrier">
+ <choice>
+ <!-- use MII/ETHTOOL ioctl -->
+ <value>ioctl</value>
+ <!-- use netif_carrier_ok() -->
+ <value>netif</value>
+ </choice>
+ </attribute>
+ </optional>
+ </element>
+ <element name="arpmon">
+ <optional>
+ <attribute name="interval"><ref name="uint"/></attribute>
+ </optional>
+ <optional>
+ <attribute name="target"><ref name="ipaddr-0-16"/></attribute>
+ </optional>
+ <optional>
+ <attribute name="validate">
+ <choice>
+ <value>none</value>
+ <value>active</value>
+ <value>backup</value>
+ <value>all</value>
+ </choice>
+ </attribute>
+ </optional>
+ </element>
+ </choice>
<oneOrMore>
<!-- The slave interfaces -->
<ref name="bare-ethernet-interface"/>
@@ -118,7 +176,7 @@
<element name="name"><ref name="device-name"/></element>
<optional>
<element name="mtu">
- <attribute name="size"><ref name="unsigned-int"/></attribute>
+ <attribute name="size"><ref name="uint"/></attribute>
</element>
</optional>
</define>
@@ -216,7 +274,7 @@
<!-- Type library -->
- <define name='unsigned-int'>
+ <define name='uint'>
<data type='unsignedInt'>
<param name="pattern">[0-9]+</param>
</data>
14 years, 11 months
Re: [netcf-devel] [libvirt] 802.1q vlan-tagging support for libvirt
by Klaus Heinrich Kiwi
On Thu, 2009-04-02 at 16:34 -0700, David Lutterkort wrote:
> Hi Klaus,
>
> On Thu, 2009-04-02 at 15:50 -0300, Klaus Heinrich Kiwi wrote:
> > My understanding is that libvirt would use vconfig to create tagged
> > interfaces, while using a physical interface as trunk (e.g., eth0 is the
> > trunk, eth0.20 the interface with the '20' vlan tag).
> >
> > Then it would add the tagged interface (eth0.20) to a bridge with the
> > guest virtual interface.
I was thinking about the semantics I described above. It ultimately
means that we'll have a bridge for each VLAN tag that crosses the trunk
interface. So for example if guests A, B and C are all associated with
VLAN ID 20, then:
eth0 -> eth0.20 -> br0 -> [tap0, tap1, tap2]
(where tap[0-3] are associated with guests A, B, C respectively)
Adding a new guest to a VLAN would mean searching the host system and
check if there is already a bridge running on that VLAN ID. Create a new
one if needed, or use the existing one.
The things that concerns me the most are:
1) How scalable this really is
2) The semantics are really different from how physical, 802.1q-enabled
switches would work.
Because (2) really creates new switches for each new VLAN tag, I wonder
how management would be different from what we have today with physical
switches (i.e., defining a port with a VLAN ID, assigning that port to a
physical machine) - unless we hide it behind libvirt somehow.
Still, things like SNMP-management can have issues with such approach
(snmp-based network managers would go crazy identifying several
switches/bridges per box - not really useful from a management PoV).
Are there other options? Since a tagged interface like eth0.20 is kind
of a virtual interface itself, would it be appropriate to use those
directly?
Or maybe extending the existing bridging code to be 802.1q-aware?
Thanks,
-Klaus
> as Dan said, the actual functionality will be provided by netcf[1]
>
> VLAN is very high on the list of things that need to be done next - and
> any help with that would be much appreciated ;)
>
> David
>
> [1] https://fedorahosted.org/netcf/
>
--
Klaus Heinrich Kiwi <klausk(a)linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center
14 years, 11 months
ANNOUNCE: netcf, a platform-agnostic library for network configuration
by David Lutterkort
I am pleased to announce the availability of netcf 0.0.1, the initial
release of a library for managing network configuration in a platform
agnostic manner. If I were into code names, this would be the "what have
you been waiting for" release.
Netcf does its work by directly modifying the 'native' configuration files
of the host it is running on; this avoids a whole class of problems caused
by similar approaches that do network configuration behind the back of the
native mechanisms. The API allows listing of configured interfaces,
defining the configuration of an interface, retrieving the same (regardless
of whether the interface was initially configured with netcf or not), and
bringing interfaces up and down. This functionality is needed both by
libvirt and NetworkManager, so it seemed only logical to move their common
needs into a separate library.
This release is mostly geared at soliciting feedback and sparking spirited
reviews. In particular, the API is not stable yet (it will be with the
release of netcf 0.1.0) Besides general comments, criticism and the
customary praise, I am particularly interested in reviews on the following:
* The API (barring any strong objections, I will declare it stable)
* The XML schema for describing network interfaces (in data/xml/interface.rng)
* General code review
Where can I get it ?
--------------------
Main website
https://fedorahosted.org/netcf/
A tarball can be downloaded from
https://fedorahosted.org/released/netcf/
The git repo is at
http://git.fedorahosted.org/git/netcf.git
git clone git://git.fedorahosted.org/netcf.git
For those running Fedora 10, I built some preliminary RPM's and made them
available at
http://people.redhat.com/dlutter/netcf/download/
(and if you are a Fedora reviewer, the review BZ is 493750 ;)
How can I help ?
----------------
Join the mailing list at
https://fedorahosted.org/mailman/listinfo/netcf-devel
Currently, netcf can set up simple Ethernet interfaces, bridges with
enslaved physical devices and bonds on Fedora. This points to two areas
where improvements are most needed:
* support other Linux distros and operating systems
* expand what kind of interfaces netcf can handle (most sorely needed are
VLAN's and adding bonds to a bridge)
If you can help with either of these two, or anything, really, drop a note
on the mailing list so wecan discuss.
David
14 years, 12 months