Ryu and OpenStack: Like Peanut Butter and Jelly

Increasingly, I’ve been spending more and more time playing around with and utilizing OpenStack. If you’re looking for a highly configurable and quickly maturing cloud operating system, you can’t go wrong with OpenStack. One of the more interesting parts of OpenStack to a networking guy like me is Quantum. Quantum allows you to create rich topologies of virtual networks, encompassing as much or as little as you want by utilizing different plugins. The plugin architecture is a nice design point, because it allows open source projects as well as vendors the chance to add value and differentiate themselves at this layer. Rather than boiling things down to a commodity, Quantum provides for extensions so each plugin can expose additional information above and beyond the core API.

Ryu and OpenStackRyu is a network operating system for Software Defined Networks. (Note: Don’t confuse Ryu the network operating system with the image above, which is of the character Ryu from Street Fighter fame.) Ryu aims to provide a logically centralized control platform for your network, with well defined APIs at the top which make this easy to manage and to build rich applications on top. If this sounds like something you’ve heard before, perhaps it’s because it’s very similar to what Big Switch Networks is doing with their Floodlight platform. One of the main differences between Ryu and Floodlight is that Ryu is written in Python, as opposed to Floodlight which is written in Java. Also, Ryu is fully compliant with OpenFlow 1.0, 1.2, and the Nicira extensions in Open vSwitch. Ryy is started and maintained by the NTT laboratories OSRG group. Ryu is licensed under the Apache 2.0 license.

There is of course a Quantum plugin for Ryu, and it’s upstream and supports both the recent Folsom release, as well as the upcoming Grizzly release of OpenStack. Instructions for deploying the plugin are available on the Ryu webpage here. You can quite quickly download a Ryu image and load it on your favorite hypervisor and be up and running in not much time. I’ve loaded and run these images on VMware ESX, VMware Fusion and VirtualBox. The images are tested on Ubuntu with KVM, but they operate just fine with other systems as well.

Running the Ryu images on your Mac

As I mentioned above, the Ryu images run just fine out of the box on Ubuntu with KVM. But I wanted to run them on my Macbook Pro. I initially wanted to use VirtualBox, but later wanted to switch them over to VMware Fusion. To start with, I needed to get them on VirtualBox. To get the images running with VirtualBox, I used qemu-img convert to convert the images into a format which VirtualBox would understand. Something like this should work:

qemu-img convert -O vmdk ryuvm2.qcow2 ryuvm2.vmdk

With that conversion, I was able to easily boot the VMs in VirtualBox. Running them in Fusion would have been as simple as copying over the converted image and importing it, but I had already configured and had the image running on VirtualBox. I moved the image to Fusion to take advantage of nested virtualization (which VirtualBox doesn’t support). So I ended up converting the images one more time before importing the VirtualBox images. I used this command:

BoxManage clonehd ~/VirtualBox\ VMs/RyuVXLANController/Snapshots/\{e5aa0713-93d1-4a06-b367-c488f29a060e\}.vmdk RyuVXLAN-d1.vmdk --format VMDK

Once I did that, I now had my configured Ryu images running under VMware Fusion, with full nested virtualization support to run nested VMs at (near) full speed.

Ryu: Segmentation

The real power with Ryu is it’s ability to segment traffic amongst tenants by using OpenFlow rules on the hosts. For VM to VM traffic across hosts it uses GRE tunnels by default. So effectively, without burning VLANs, you are now able to create rich network topologies scaling to very high tenant limits. For something like OpenStack, this is very useful, as typically OpenStack deployments have many tenants, and this allows for scaling tenant networks on demand.


In summary, Ryu is a great platform for virtual networks when deployed with OpenStack Quantum. Scaling tenant networks utilizing a combination of OpenFlow and GRE tunnels is not only very cool, but very practical. Plus, how cool is it to be able to say you’re running an Open Source IaaS Cloud Operating System and utilizing an Open Source SDN Operating System for your networking needs? I think that’s a pretty awesome scenario.