netcf-devel

netcf-devel@lists.fedorahosted.org

270 discussions

SuSE driver
by Jonas Eriksson 26 Jun '09

26 Jun '09

The things I have tried worked. I have a few problems, though: ' and " are not handeled. As bridges SuSE have their own ifcfg-file, the BRIDGE_PORT contain the interfaces used in that bridge, separated by whitespaces. My problem is mostly whether to extend shellvars.aug to handle ' and ", or if this should be handled in C/XSLT. In SLE10, interfaces could be named after their mac address using eth-id-<mac>. This is now defunct and handled by udev-rules, but I have somewhat retained handling of this, but convert it to ethX-syntax. However, when facing an interface-element in netcf-xml with a mac address, I convert this to a eth-id-interface in XSLT, and then to ethX in C by looking up the mac. Instead of doing this, the driver should retain the original ethX-name as an fallback in case the mac is not found. Whenever using define in netcf, i get: error: unspecified error error: aug_save failed After doing some dry runs with augtool, I have concluded that this is most probably due to augeas trying to save the address-files in /sys. Is this a problem when using the initscript-driver as well? Currently, there is a mix between functions that accept name or path. I am planning to clean up this mess, preferably standardizing on name as argument. I also have a few questions/opinions: Should we include some general debug macros? I stole the ones from libvirt and removed them before this post, and i had alot of use for them, for example to see the <forest>-xml when doing a define. Alot of code are the same between the initscript driver, and probably will be for other drivers as well. I recommend that this code is broken out, for example to a Linux-helper? The same goes for both C-code (e.g. handling of mac-address lookups) and XSLT (e.g. bonding-options). I changed the augeas save-behaviour to "backup" in the augeas init function (which probably also could be lifted out to a general helper file). I left it in there, since I like it alot, but we should probably discuss it further. Regards, Jonas -- Jonas Eriksson Consultant at AS/EAB/FLJ/IL Combitech AB Älvsjö, Sweden

2 7

Multiple interfaces with identical mac-addresses
by Jonas Eriksson 25 Jun '09

25 Jun '09

Hi, Looking through the driver API, I came across the drv_lookup_by_mac_string. This function is prototyped in internal.h, so I assume that it is a part of the public driver API. However, a problem may arise when multiple top-level interfaces share mac addresses, as drv_lookup_by_mac_string only may return one struct netcf_if *. This can occurr when using vlan interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be considered top-level interfaces, the bridges or bonds that these interfaces are a part of. I therefore recommend a switch to a drv_list_interfaces-prototype for drv_lookup_by_mac_string. For reference: int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names); Best regards, Jonas Eriksson -- Jonas Eriksson Consultant at AS/EAB/FLJ/IL Combitech AB Älvsjö, Sweden

6 13

[RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
by Laine Stump 22 Jun '09

22 Jun '09

I've already been working on incorporating physical host interface configuration into libvirt by way of using libnetcf on the backend. It's becoming apparent that, in addition to modifying and reporting the current configuration of interfaces, libvirt users also want to query current status of each interface (up/down, possibly other flags, packet/byte/error counts, current IP address, etc). There are two possible ways of doing this: 1) maintain libnetcf's focus on just interface configuration, and add code directly into libvirt to grab this information via appropriate ioctls or 2) add the functionality to libnetcf, and have libvirt call the new libnetcf API. (2) seems to make the most sense, because likely other libnetcf consumers will want this capability too. I'm thinking of a single API, something like: int netcf_if_status(netcf_if *, netcf_if_stats *); (or maybe int netcf_if_info(netcf_if *, netcf_if_info *)) I haven't really put much thought into the details of what should be in netcf_if_stats yet (beyond what I listed above), but wanted to get this idea out there so people can start sounding off (if I'm going down the wrong road, I'd rather be put on the right path before I get too far along!) This function could be exposed in the libvirt API as something like: int virInterfaceStatus|Info(virInterffacePtr iface, virInterfaceStats|Info *info); Any comments/ideas on this? (One possible complication I can see is interfaces with multiple associated IPs. On some platforms, each interface can have only a single IPv4 and a single IPv6 address (more IPs == more interfaces), but on others there can be multiples.) A (kind of) separate issue: In libvirt we want to be able to list active (up) and inactive (down) interfaces separately. For consistency, libvirt's way of exposing that will be to mimic what is done with virConnectListNetworks() (active) vs. virConnectListDefinedNetworks() (inactive). But netcf could do it with an extra argument to ncf_list_interfaces(). If the latter, should the default behavior be to list all interfaces, with flags set to eliminate up or down interfaces? 0 (list all) NETCF_NOLIST_UP NETCF_NOLIST_DOWN Or should the values be something like this: 0 (list all) NETCF_LIST_UP_ONLY NETCF_LIST_DOWN_ONLY (UP_ONLY + DOWN_ONLY would be equivalent to 0. As long as nobody came up with a good reason for "0". So should we do one of those, or should we mimic libirt's virNetwork API in libnetcf too?

5 56

Enclose IPv4 related info in <protocol> tag
by David Lutterkort 20 Jun '09

20 Jun '09

This change requires that <ip>, <dhcp> and <route> elements be enclosed in a <protocol family='ipv4'> container tag, so that we can add additional protocols without too much headache. The patch does not change the fact that only IPv4 can be used right now, nor that an interface can have at most one address.

1 1

Allow lookup_by_mac to return multiple interfaces
by David Lutterkort 19 Jun '09

19 Jun '09

This is the incompatible API change that I discussed with Jonas Erikson a couple of weeks ago. The change makes sure that we can return multiple interfaces when looking up by MAC. David

1 1

Monitoring of bonds
by David Lutterkort 19 Jun '09

19 Jun '09

This patch adds the all-important monitoring options for bonds as two new elements inside the <bond> element: <miimon> to set up MII monitoring, and <arpmon> to set up ARP monitoring. For details of the options involved from the bonding driver, consult Documentation/networking/bonding.txt in a kernel checkout near you. I am posting this mostly because I would like somebody to look over the schema changes in interface.rng for all this, but of course comments on how this is implemented are very welcome, too. David

1 1

Bridge XML-API
by Jonas Eriksson 05 Jun '09

05 Jun '09

Hello I am currently looking in to the use of netcf with libvirt and have found a problem with the XML-API that i would like to have some input on. According to interface.rng, a <bridge>-element require one or more <interface>-children. A scenario where one would like to create empty bridges would for example be when connecting two virtual machines, running in a hypervisor where a vif/tap-pair is created dynamicaly at VM start and then added to the specified bridge. It is not in all cases wanted that these VMs are connected to any kind of outside world, and therefore require another interface in the bridge. Because of this, I argue that zeroOrMore is used instead of oneOrMore for <interface>s inside a <bridge>-element. Best regards, Jonas Eriksson -- Jonas Eriksson Consultant at AS/EAB/FLJ/IL Phone: +46 8 58086281 Combitech AB Älvsjö, Sweden

3 7

More bonding parameters
by David Lutterkort 18 Apr '09

18 Apr '09

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> + +  + + <choice> + <element name="miimon"> +  + <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> +  + <attribute name="carrier"> + <choice> +  + <value>ioctl</value> +  + <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>  <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 @@  - <define name='unsigned-int'> + <define name='uint'> <data type='unsignedInt'> <param name="pattern">[0-9]+</param> </data>

1 0

Re: [netcf-devel] [libvirt] 802.1q vlan-tagging support for libvirt
by Klaus Heinrich Kiwi 08 Apr '09

08 Apr '09

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

4 3

ANNOUNCE: netcf, a platform-agnostic library for network configuration
by David Lutterkort 03 Apr '09

03 Apr '09

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

netcf-devel