Author Archives:

OpenStack and oVirt: Fitting the Pieces Together

Posted by mestery on

Many readers of this blog, as well as my work on the Open@Cisco Blog, will be familiar with both OpenStack and oVirt. I have written many posts on OpenStack and oVirt, but what I want to do with this post is compare the two. Examining where each project has it’s roots, as well as it’s current status and how the two Open Source projects may converge in the future, is a worthy exercise.

OpenStack

OpenStack comes to us by way of Rackspace Cloud and NASA. It has as it’s origins a very ambitious goal: Allowing anyone to run a cloud computing infrastructure on whatever hardware you have in your data center. OpenStack has quickly consumed a large amount of industry attention, garnering support from a large swath of datacenter vendors as well as service providers. OpenStack has had many successful releases, and the developers are currently working towards a fall release of the IaaS software called “Folsom”.

oVirt

oVirt came into existence when Red Hat decided to Open Source the final piece of it’s Qumranet acquisition. Qumranet had built a datacenter virtualization management application using Microsoft’s .NET framework. Red Hat spent a large amount of time porting this code over to Java. The result is oVirt, which was released to the world at a Kickoff Workshop hosted by Cisco, the company I work for. The first release of oVirt came about on February 9, 2012. The oVirt team is hard at work on the next release at this time.

OpenStack and oVirt: Apples and Oranges?

From a distance, it’s easy to look at oVirt and OpenStack and think they may somehow be competing projects, both looking to solve the same problem. But once you dig into them, it becomes clear their short-term goals are very different. OpenStack, by virtue of it’s IaaS roots, is trying to solve the mulit-tenant datacenter problem. By focusing on massive scale, both in terms of nodes as well as tenants, it wants to let you run an AWS scale IaaS cloud in your own datacenter. oVirt, on the other hand, is focusing on a scale much smaller. It wants to let you manage a pool of resources so you can distribute your virtual workloads across them in an efficient manner. By focusing on a different set of users, the two technologies currently each have an important place in the datacenter. Their intersection may not be obvious currently, but OpenStack Quantum may be the first bridge between the two projects.

OpenStack Quantum: Bridging the Gap

One area where a bridge appears to be forming between the two technologies is with Quantum. Quantum is the networking technology, incubating in OpenStack, which will be used to construct rich network topologies for OpenStack clouds. It has broad vendor support, and will allow for networking vendors to plug their technology underneath to implement Quantum’s network and port constructs. When the Folsom release of OpenStack appears this fall, Quantum should become the default networking option in OpenStack.

In the fall of 2011 during the OpenStack Kickoff Workshop, the subject of Quantum and how it relates to oVirt was approached. I blogged about this here, noting at the time:

Now that the oVirt Kickoff Workshop is over, watching how the networking story with oVirt evolves will be interesting. The success of oVirt will be the result of the community around it, and the ecosystem for third party vendors it creates. With regards to networking in oVirt, the interactions between the Quantum community and the oVirt community have only just begun, and the future looks like a very collaborative affair between the two projects.

Those words ended up being very prescient, as there has been recent work to integrate Quantum into oVirt as a POC. This work has been done by some engineers at Red Hat, and the interesting thing about the work is how the network is the first technology being abstracted out of both OpenStack and oVirt via Quantum.

Future Interactions

In a previous post, I had compared oVirt to VMware vSphere, and OpenStack to vCloud Director. Once you make this comparison, it’s easy to see how you could at some point see OpenStack managing oVirt clusters. OpenStack has various virtualization drivers in Nova to handle interacting with virtualization platforms such as Xen, KVM, and Hyper-V. Adding a new driver to interact with oVirt would allow for an interesting interaction between the two technologies. Allowing OpenStack to schedule tenant workloads across oVirt clusters sounds interesting, and may be worth exploring in the future. Perhaps as the two projects converge in the middle, more interesting ideas will surface around these two vibrant Open Source projects.

Conclusion

As oVirt nears it’s second release, and OpenStack roles towards the projects sixth release, understanding where the projects exist today is important in looking at how their paths may cross in the future. OpenStack Quantum is acting as the first bridge between the two projects. But as the worlds of datacenter virtualization come together with IaaS cloud computing, the two projects fates may twist together to provide ultimate value for developers, users, and customers.

devstack on Fedora

Posted by mestery on

So, it should come as no surprise that I’m a big Fedora user. I’ve been running Fedora since Core 1 came out years ago, and I’ve always been a happy user. As my world has converged around OpenStack recently, the easiest way to work in this environment is by using devstack. For a long while, devstack only workd with Ubuntu. It now supports Fedora, as well as using Qpid instead of the regular RabbitMq.

Working with devstack on Fedora is the same as using it on Ubuntu, and I can happily report it works great. I’ve run multiple copies of Nova compute on different machines even, and it all just works. So go forth and deploy devstack on Fedora with confidence!

For reference, here is the Fedora wiki page detailing devstack on Fedora. Also, my localrc file looks like this, for reference:

MESSAGING_SYSTEM=qpid
IMAGE_URLS=”http://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-uec.tar.gz,http://berrange.fedorapeople.org/images/2012-02-29/f16-x86_64-openstack-sda.qcow2″
ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-net,n-sch,n-vnc,horizon,mysql,qpid,openstackx,quantum,q-svc,q-agt
Q_PLUGIN=openvswitch
USERNAME=admin
RABBIT_PASSWORD=nova
MYSQL_PASSWORD=password
SERVICE_TOKEN=password
SERVICE_PASSWORD=password
ADMIN_PASSWORD=password
HOST_IP_IFACE=eth0
PUBLIC_INTERFACE=eth1
VLAN_INTERFACE=eth1
FLAT_INTERFACE=eth1

CloudStack Goes Apache

Posted by mestery on

The announcement from Citrix that they are migrating CloudStack to the Apache Foundation under the ASL 2.0 license is a move indicative of what it takes to succeed in large scale cloud computing. Cloud computing isn’t like normal off the shelf software. Cloud computing requires building an ecosystem of developers  around it. In essence, it requires a community of people deeply committed to the project. If anything, OpenStack has helped to prove this, as it’s one of the fastest growing Open Source projects ever. As organizations look to deploy large scale clouds on premise, they need to consider building, deploying, and managing these clouds. Ensuring your cloud software has a thriving developer community, with access to source code, ensures the engineers you are using to build your cloud have the tools they need to succeed. It also means they have places to look for help. And source code means any problem can be fixed in house if needed.

CloudStack going Apache should help it gain some traction and credibility, now it needs a large and thriving ecosystem of developers to maintain the momentum the announcment will bring with it. 2012 is shaping up to be an interesting year in the Open Source Cloud Computing world.

See also:

  • Comments by Randy Bias on the decision.
  • Analysis by Krish.
  • Why cloudStack joining Apache is good news, by Lars Kurth at xen.org

SDN Adoption in the Enterprise

Posted by mestery on

This post by Brad Casemore is rather interesting. Specifically, I love this comment:

When it comes to technologies and markets, our inherent optimism occasionally is thwarted by our intrinsic resistance to change.

This is true everywhere, but especially true in technology. I’m not saying SDN won’t penetrate the enterprise market, and neither is Brad. It will take time, for sure. What will help SDN penetrate this market is the value built on top of it. Applications provide business value, and once they can orchestrate the network to their needs, the game changes. A good example is this post by Brad Hedlund on Hadoop Clusters and the Network. Allowing a distributed piece of software like Hadoop to understand the network allows it to work more efficiently. This is an example of what will help to drive SDN adoption in the enterprise going forward.

Comments Are Bile

Posted by mestery on

Subject stolen from the eloquent MG Siegler, who writes here about his feelings on comments on blog posts. I have to say, I agree 100% with him. I’ve spent way too much time trolling spam comments over the last few months. I realized it’s just not worth it. Like MG says, anyone who wants to respond to a post on this site can do so by contacting me on twitter.

Hate email? Remember Google Wave?

Posted by mestery on

It’s that time of year again where everyone goes off on email. Fred Wilson does it here, and MG Siegler does it here. I quote from MG’s article here:

The only real “solution” is to change the way people think about email. It needs to be considered more of a stream than an inbox. That is, it needs to be more like Twitter and less like a to-do list.

As much as everyone hated Google Wave, it was ahead of it’s time in changing how email was used. I quote the aforementioned MG from a TechCrunch article:

Having seen a lengthy demonstration, as ridiculous as it may sound, I have to agree. Wave offers a very sleek and easy way to navigate and participate in communication on the web that makes both email and instant messaging look stale.

So what ultimately drove Wave into the ground? Again, let MG’s own words guide us:

I like to think my own natural usage of a new service is a pretty good barometer of how well it will do. And I’ll be honest, like seemingly everyone else, I wasn’t using Google Wave. But the weird thing is that I wanted to use Google Wave, I just wasn’t presented with a compelling reason to do so. And that’s on Google.

Ultimately whatever solution leads us away from “email hell” will need to be compelling, addictive, and useful. Wave wasn’t all of those. Who will build a service combining all three elements? The Apache Software Foundation has taken over the Google Wave code, perhaps in the hands of an Open Source Community the freshly renamed Apache Wave can succeed where Google failed: making Wave something people want to use.

Update on VXLAN in Open vSwitch

Posted by mestery on

So, previously on the other site I blog for, I mentioned VXLAN in OpenStack Quantum. The reasons for this are dictated in that post. While we can start working on the segment ID and multicast address management in Quantum, getting VXLAN support into Open vSwitch can be done in parallel. That process has seen renewed interest recently (see the thread here), and I am happy to report I have setup a git repository with the patches from last fall merged into the latest master branch versions of Open vSwitch. To get the code, go here. At this point, you have to manually configure the tunnel endpoints, but passing traffic should work over the VXLAN tunnels.

I hope to work with other Open vSwitch developers in the coming weeks to get a fully realized and deployable version of VXLAN into Open vSwitch. At the same time, work will start on the management hooks into OpenStack Quantum. Stay tuned for the blueprint proposing this for inclusion into OpenStack Quantum soon.

Moving a Cisco NSSxxx from Cisco Firmware to Qnap Firmware

Posted by mestery on

So, Cisco (disclaimer: I work at Cisco, although not in the group working on the NSSxxx products) has recently decided to stop selling their Qnap OEM’d NAS devices. See the link here. For those of us who have one of these in our labs (I have a NSS326 myself), this means no more firmware updates from Cisco. But, the latest firmware for these devices from Cisco (version 1.5, Release Notes PDF here) does allow for users to migrate from Cisco firmware to the stock Qnap firmware. So, how easy of a process is this? I was able to do this myself, I thought I would document the steps for others to follow here.

  1. You may want to backup your data first. I did not do this, but depending on how important your data is, it’s wise to consider this step.
  2. First, acquire the NSS 1.5 firmware from cisco.com. Once you have that, go ahead and load this onto your NSSxxx device and reboot.
  3. Once the device is running 1.5, go ahead and download the latest Qnap firmware for your device (link here).
  4. Load the Qnap firmware onto your device, and reboot.
  5. You should now be running the stock Qnap firmware for your OEM’d Cisco NSSxxx device.
One of the main advantages of this transition is that the Qnap firmware supports Time Machine with OSX Lion, whereas the Cisco firmware does not. If you are running Macs in your lab, business, or home, this is reason enough to migrate to the Qnap firmware. Qnap will also continue to support software updates on the Cisco NSSxxx, so this is another good reason to migrate.

One issue I did hit when migrating was that I had ssh access enabled on my Cisco, but when I moved to Qnap, the default ssh worked, but only allowed a single ssh login at a time. I migrated to OpenSSH by following the instructions here. This worked well, and allows me to have multiple ssh sessions going to the Cisco NSSxxx.

Open Source Cloud and Virtualization Terminology for VMware Users

Posted by mestery on

Recently, as I was talking to a friend about OpenStack, oVirt, and other Open Source Cloud and Virtualization technologies, he stopped me and had me back up. This friend has a strong background in VMware technologies, but not so much with their Open Source counterparts. It occurred to me there are others who may be coming from the same VMware background, thus I decided to create a handy cheat sheet for folks new to Open Source Cloud and Virtualization technologies who have a VMware background.

And with that, I present the cheat sheet below:

  • KVM: KVM is a hypervisor integrated into and utilizing the Linux Kernel. Comparable VMware technology: The ESXi vmkernel
  • Xen: Xen is another hypervisor integrated in the Linux kernel. Comparable VMware technology: The ESXi vmkernel
  • Qemu: A generic Open Source machine emulator and virtualizer. KVM uses this as the virtual machine monitor for running virtual machines. Comparable VMware technology: ESX virtual machine monitor
  • oVirt: oVirt is a complete and comprehensive infrastructure and management virtualization platform for the data center. Comparable VMware technology: vSphere
  • ovirt-node: ovirt-node is a small footprint Linux distribution, running the KVM hypervisor. Comparable VMware technology: ESXi
  • Aeolus: Aeolus is a management platform for running virtual machines both in your own datacenter, as well as in a public cloud. Comparable VMware technology: vCloud Director
  • OpenStack: OpenStack, per the website, “delivers a massively scalable cloud operating system.” For the most part, OpenStack itself compares favorably to a vCloud Director setup. Comparable VMware technology: vCloud Director
  • OpenStack Nova: Nova is the compute manager for OpenStack. It handles spinning VMs up, bringing them down, and managing resources of the compute nodes. Comparable VMware technology: Functionality in vCenter
  • OpenStack Swift: Swift is an object storage system for OpenStack. Comparable VMware technology: VMFS (to some extent)
  • OpenStack Glance: Glance provides virtual machine image management for OpenStack. Comparable VMware technology: Functionality in vCloud Director
  • OpenStack Keystone: Keystone is an identity management system providing uniform authentication across OpenStack. Comparable VMware technology: Functionality in vCenter
  • OpenStack Horizon: Horizon is a GUI designed to allow administrators to work with OpenStack in a self service portal. Comparable VMware technology: Parts of vCloud Director
  • OpenStack Quantum: Quantum is a service providing the ability to provision and manage networks in OpenStack. Comparable VMware technology: Features found in vSphere/vCloud Director
  • Open vSwitch: Open vSwitch is an open source virtual switch, which can run inside the Linux kernel and work with both KVM and Xen. Comparable VMware technology: VMware vDS and Cisco Nexus 1000V
  • OpenFlow: While not technically an Open Source project, OpenFlow is essentially an Open Source networking protocol. Comparable VMware technology: Nothing currently
Hopefully the list above is a good comparison for people new to Open Source Cloud and Virtualization solutions coming from a VMware background.

Open vSwitch Kernel Code Moves Upstream

Posted by mestery on

Just a note that over the weekend, after a few weeks of reviews, the Open vSwitch Kernel Code has moved upstream. Dave Miller pulled the code this weekend. Getting this upstream will be really helpful for OpenStack Quantum, as the default plugin for that code uses OVS. This is also great for distributions who want to include OVS, but have been hesitant because of it’s lack of existence in the upstream kernel.

Congrats to the folks at Niciria and others who worked hard over the last 3 years to make this milestone!