If you’ve been playing with kvm for a while now you know what a hassle network configurations can be. For some of us it’s fun but if you’re relatively new to linux, it can be a painful experience. With projects like virt-manager and libvirt in development, network configurations are becoming much more bearable. These gui tools however have come up against a wall when it comes to more complicated network setups such as bridging, bonding interfaces etc. One of the main reasons for this is that there’s no standard for network configuration scripts across different linux distributions making it virtually impossible for a GUI tool to do anything more than NAT configurations.
In steps netcf, a new project announced in April that looks very promising.
Netcf is described as a cross platform network configuration library. It works by modifying the native configuration files on your linux distribution directly. When you really think about it, it’s a wonder why something like this wasn’t done before. Anyway, back to what I was saying.. It’s API allows you to perform certain operations on your network configurations such as listing, defining, retrieving and also setting your network interfaces to up/down. Along with the library comes a command line tool called ncftool which allows you to do all this interactivey in a shell like environment. The other thing about netcf is that the API accepts xml descriptions making integration with libvirt natural since it too is xml friendly. This puts netcf in a position where it’s not only cross platform but it will also be useful for both physical and virtual machine network configurations. You can see where this is going already; all GUI tools using libvirt will inherit this functionality eg. Virtual Machine Manager.
Let’s take a concrete example so you can see the ncftool in action. First you’ll need to install the packages netcf and netcf-libs. If your distributions doesn’t have it you’ll have to download and install from source. You can probably use the git repo for now which is at git://git.fedorahosted.org/netcf.git.
Invoke the tool by simply typing ncftool and you’ll be thrown into interactive mode as shown below.
[root@localhost ~]# ncftool ncftool>
If you type help, you will see just a handful of commands.
list - list network interfaces dumpxml - dump the XML description of an interface define - define an interface from an XML file undefine - undefine an interface ifup - bring up an interface ifdown - bring down an interface help - print help quit - exit the program
To dump your current network interface to a netcf xml format, issue the dumpxml command.
ncftool> dumpxml eth0 <?xml version="1.0"?> <interface type="ethernet" name="eth0"> <start mode="none"/> <mac address="00:19:B9:7E:C8:63"/> <protocol family="ipv4"> <dhcp peerdns="yes"/> </protocol> </interface>
If you wanted to configure your network interface using ncftool, you would create an xml file similar to the output above and enable the configuration using the define command from within ncftool. For example, if your ethernet interface was using a static ip address you could define it in an xml file with the following contents adjusting for interface name. Let’s say you called this file /tmp/ethernet.xml.
<interface type="ethernet" name="eth1"> <start mode="onboot"/> <protocol family="ipv4"> <ip address="192.168.0.5" prefix="24"/> <route gateway="192.168.0.1"/> </protocol> </interface>
Once this is defined, start ncftool and define the configuration like so
ncftool> define /tmp/ethernet.xml
The ncftool then configures your interface according to the xml definition. You can then look to your network scripts to verify the configurations. At this time, ncftool/netcf is capable of configuring bonding, vlan interfaces, bridges and interfaces. For baseline xml configurations you can use the templates found here.
You can find more information about this project at the following page
Linux virtualization has spawned dozens of related projects this being another one of them. However, its apparent that this project would prove useful even without considering virtualization. I think this will help push the automation of network configurations further along for both physical and virtual machines.