CloudStack Goes Apache

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

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

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?

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

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

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

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

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!

ForCES: SDN You’ve Never Heard Of

With all the hoopla surrounding SDN, in all of it’s forms, I thought it would be interesting to look at a possible predecesor to OpenFlow, at least in spirit: The ForCES protocol. From RFC 5810, we have the following description of ForCES:

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE).

For OpenFlow, if we look at wikipedia for a quick definition, we see the below:

OpenFlow is a communications protocol that gives access to the forwarding plane of a network switch or router over the network.[1] In simpler terms, OpenFlow allows the path-of-network-packets-through-the-network-of-switches to be determined by software running on a separate server. This separation of the control from the forwarding allows for more sophisticated traffic management than feasible using access control lists (ACL)s and routing protocols.

In essence, what OpenFlow is proposing (separation of control and forwarding plane), was proposed years earlier by ForCES. While ForCES has been around in the IETF for years (there are even old mailing list archives here), it has never achieved OpenFlows level of celebrity. I guess, even for network protocols, timing is everything.

LimeChat: OSX IRC Client

I’ve recently started attending IRC meetings. Since I run a Mac, I had to do some digging to understand the best possible IRC clients out there. Fairly quickly, I discovered LimeChat. It’s a very versatile IRC client, the UI is pretty clean, and it doesn’t appear to suck a ton of resources. Overall, I’m quite happy with it, and would recommend it for anyone looking for a slick IRC client on the Mac. Check it out either at the website above, or in the Mac App Store.