Experimenting with Kernel-powered Open vSwitch and Docker

Posted by Dave on 28 August 2014

I've been thinking about running Docker on CoreOS and Project Atomic lately... While the deployment model would be pretty different to what we are used to, I have 50% of the work already done in docker-ovs so I was interested to see if my containers would work on a system with the Open vSwitch kernel module loaded...

As I'm a Mac User, I use boot2docker for all my docker-related things. It's also pretty easy to change the kernel config to allow the Open vSwitch module to be loaded.

  1. Install boot2docker

  2. Clone my fork

  3. git checkout openvswitch

  4. Build the iso

docker build -t boot2docker . && docker run --rm boot2docker > boot2docker.iso
  1. Run boot2docker with the new iso
boot2docker destroy
boot2docker init --iso="`pwd`/boot2docker.iso"
boot2docker up
  1. Load the Open vSwitch kernel module
boot2docker ssh
sudo modprobe openvswitch
  1. Run an Open vSwitch container
docker run -t -i --privileged=true davetucker/docker-ovs:2.1.2 /bin/sh
export OVS_RUNDIR=/var/run/openvswitch
sed -i s/nodaemon=true/nodaemon=false/g /etc/supervisord.conf
  1. Test it out
ovs-vsctl add-br br0
ovs-vsctl show
# This didn't work before
ovs-dpctl show

This isn't a thorough test. I'd like to create some traffic and see the flows installed in the kernel but I'm just happy that ovs-dpctl is working.

Based on my current understanding of OVS, it should be possible to just containerize the userspace agents and use the kernel module that has been in the upstream Linux kernel since 3.3. The one caveat here is that new features that are added to OVS may either have poor performance or be unsupported until an kernel module has been contributed upstream. However with OVS, VXLAN and GRE support already in the current stable kernel I think that is a compromise I can live with!

If you are still using docker-ovs for CI, this means that you can use the kernel datapath too and I'll be updating the docker-ovs README to explain how to do this in due course...

The one area that remains to be explored is to see if multiple containers can share the kernel module in the host system. Hopefully I'll find some time to explore that in the near future :)