Exploring RHEL-OVS Integrations

In this post, I’m going to explore some integrations between Red Hat Enterprise Linux (RHEL)/RHEL variants and Open vSwitch (OVS). This post will lay the foundation for a future post describing OVS automation using Puppet.

Over the past few weeks, I’ve been rebuilding my home lab to focus on some core projects/technologies for the upcoming year (more on that in this post). As part of the rebuild effort, I’ve rebuilt my hosts to run CentOS 6.3 x64, KVM, Libvirt, GlusterFS, and OVS, and have crafted Puppet code to help install (and configure, in some cases) most of these components. This post, as with some others, is an offshoot of the lab rebuild work.

(In case you were wondering, the other posts that have come out of the home lab rebuild project include building Libvirt RPMs, using Mock to build Sanlock RPMs, using Mock to build libssh2 RPMs, using Mock to build Libvirt RPMs, and using Puppet for user accounts and configuration files. I’m sure there will be more.)

The information in this post will build upon some base OVS knowledge, so if you aren’t familiar with OVS, then you might want to go back and read some of my earlier OVS posts (these will at least get you started):

Some Insight into Open vSwitch Configuration
Link Aggregation and LACP with Open vSwitch
VLANs with Open vSwitch Fake Bridges
Running Host Management on Open vSwitch
Layer 3 Routing with Open vSwitch

Finally, before we get into the real meat of the information, I’d like to point out that the information in this post builds upon the information already included in the OVS documentation (see the README.RHEL file in the distribution tarball). I’m merely attempting to provide some additional context and examples on how these can be used.

Now that the preliminaries are out of the way…

The basic gist of the RHEL-OVS integration is support for the use of the scripts in /etc/sysconfig/network-scripts to do some configuration of OVS itself. For example, creating bridges, establishing bonds, configuring internal ports—all these tasks can be done using an ifcfg-<name> script.

Let’s start with a very basic example. Let’s say that you want to create a single OVS bridge named ovsbr0. To do that, you’d create a file named ifcfg-ovsbr0 in the /etc/sysconfig/network-scripts directory, and make the contents look like this:

Now let’s say that you want to create a link aggregate on that bridge. To create a link aggregate on ovsbr0 (the bridge you just created), create a file named ifcfg-bond0 in the same directory, and make its contents look like this:

Note that this is an LACP-enabled link aggregate, so you’ll also have to configure your physical switch appropriately.

Finally, suppose that you want to create an internal interface (it will appear as a physical interface to Linux, but is hosted on OVS) across which you can run your management traffic. No problem! Just create a file named ifcfg-mgmt0 and make the contents of the file look like this:

Each of these scripts will create the corresponding structures/configurations within OVS. There is a drawback, however. In order for these changes to take effect, you must restart the network (perform a service network restart). This doesn’t appear to be an OVS limitation of any sort; if you’ve read any of the other OVS posts, you know that you can make these changes live via the ovs-vsctl command. Instead, it simply appears to be a limitation of the fact that these scripts are only evaluated during a network stop/start event.

Once these scripts have been evaluated, though, you should end up with a configuration that looks something like this (UUIDs have been changed to protect the innocent):

Given the limitation, I can imagine that a natural question to ask would be, “Why use this integration, which requires a network restart, when you could just make the configuration changes yourself?” Excellent question. I see this as a way of establishing a “baseline” configuration for OVS, upon which you could (dynamically) add all the other configurations you need. In addition, because the base OVS configuration exists as a set of files, this opens up some other interesting possibilities. I’ll explore those possibilities in a future post.

As always, courteous comments are welcome, so feel free to add your questions, thoughts, corrections, or clarifications in the comments below.

Tags: , ,

  1. Mark Sutton’s avatar

    Nice blog, I’m gonna go and read some of your earlier posts too! I had one thought though -

    Instead of a full network restart, you could try:

    # ifup ovsbr0 && ifup bond0 && mgmt0

    Never tried it with OVS but it should work…


  2. Travis’s avatar

    If they’re like the other ifcfg-* scripts in /etc/sysconfig/network-scripts you should be able to `ifup ovsbr0` and `ifdown ovsbr0` (etc.) without having to resort to a `service network restart`

  3. Stephan’s avatar

    I’m just configuring a Scientific Linux Server (6.4) with OVS (1.11) and your blog did help me a lot, but I could not get the bond0 interface to work.

    To get bond0 work you must use another ifcfg-file for eth0 and eth1 that contains only three lines:

    DEVICE=eth0 or eth1 respectively

    If you setup eth0 or eth1 like described here, the bond will not work, since eth0 and eth1 are already ports of ovsbr1.

  4. Ashraf Khalid’s avatar

    hi Scott,

    thanks for the wonderful blog on OpenVSwitch. All of your article are quite apt for people who are starting with OVS, and unfortunately none of the documents on OVS address clearly to the key aspects like LACP, Bonding, VLAN interface/tagging.

    Can you update this blog with the network script for a fake bridge as well?
    say, a fake bridge named vlan100 under the main bridge “ovsbr0″ for VLAN=100?

    I think this blog will be quite convincing and more or less complete with its reference.

    Thank you!

  5. slowe’s avatar

    Ashraf, I’m pretty sure all of the topics you mentioned in your comment have already been addressed in other articles. Have a look at articles tagged OVS. Thanks!

  6. Ashraf Khalid’s avatar

    I have found this configuration (Variables and Values) which can be used for configuring network scripts in RHEL/CENTOS/Fedora for Fake Bridges.

    I hope it comes handy for people like me.

    Please find an example network script below:

    OVS_OPTIONS=”ovsbr0 100″
    NAME=”Fake Bridge named VLAN100 under main bridge OVSBR0″


Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>