Private cloud platforms: OpenStack and OpenNebula

Picture a research computing group at KFUPM that owns 40 servers. Today a student who needs a GPU virtual machine emails an administrator and waits about a week while someone carves out the machine by hand. Now install a private cloud platform on those same 40 servers. The student logs into a web dashboard, picks an image and a size, and the machine is running in about a minute. Nothing about the hardware changed. What changed is that the servers became a shared pool that users draw from themselves, and every draw is counted.

That is exactly the list of NIST traits from earlier in this lecture: On-demand self-service, Resource pooling and Measured service. NIST defines a Private cloud as cloud infrastructure provisioned for the exclusive use of a single organization, whether it sits on or off the organization's premises. A private IaaS platform is the software that makes this real. It turns a pile of servers, disks and switches into on-demand compute, networking and storage, exposed through an API and a dashboard. The research literature calls OpenNebula a "virtual infrastructure manager" for exactly this reason: it takes infrastructure you already have and turns it into a private or hybrid IaaS cloud.

The market for this software is large. Products span the whole stack from IaaS up to SaaS, and they split into two families. Some are open source, such as OpenStack andOpenNebula, which the rest of this part studies. Others are licensed commercially and charge fees per socket, per core or per node. Choosing open source does not make the cloud free: you still pay the capital expense for hardware and the staff to run it, as the TCO case study showed. What it buys is control, and freedom from Vendor lock-in at the platform layer.

In 2010 two organizations each had half of a cloud. Rackspace, a hosting company, wanted its Cloud Files storage code to become an industry standard rather than a private product; that code became Swift. Anso Labs, contracting for NASA Ames, had published Nova, a Python "cloud computing fabric controller" for NASA's Nebula cloud. The two efforts merged. The first Design Summit met in Austin on 13 to 14 July 2010, the project was announced at OSCON on 21 July 2010, and the first release, named Austin, shipped on 21 October 2010.

The project's stated mission was a platform for both public and private clouds, and the official guide still calls OpenStack "an open source cloud computing platform for all types of clouds". What made it last is governance. In September 2012 the OpenStack Foundation took over stewardship, so no single vendor owns the code. In October 2020 it was renamed the Open Infrastructure Foundation (OpenInfra), and in 2025 it joined the Linux Foundation. The code is licensed under Apache 2.0 and ships on a fixed 6-month cycle with alphabetical names: 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho, and 2026.2 Hibiscus, released on 30 September 2026.

The fastest way to understand OpenStack is to follow one command. A user types the command below to start a small Ubuntu machine on a private network. That single line touches six separate services before a Virtual machine (VM) exists.

openstack server create --image ubuntu-24.04 --boot-from-volume 20 --flavor m1.small --network private demo-vm

The architecture rule behind the trace

The trace shows the design rule. OpenStack is a set of independent services, and each one owns one kind of resource and exposes it through a REST API. Every service authenticates callers through Keystone, and services talk to each other only through those public APIs. Inside a single service, its worker processes coordinate through an AMQP message broker such as RabbitMQ, and each service keeps its state in its own SQL database. Horizon, the web dashboard, has no special powers: like the CLI, the SDKs or a plain curl, it is simply another REST client.

This design is why OpenStack scales to large operators and why it is heavy to run. Each service can be scaled, upgraded and replaced on its own, but a production cloud means operating many daemons, a message broker and several databases. Its feature list mirrors a Hyperscaler almost one for one, which makes the AWS comparison the easiest way to remember it.

Now take a mid-size company leaving VMware. It installs one OpenNebula front-end on a single VM, adds ten KVM hosts and a Ceph datastore, and gives its staff the Sunstone web interface. That is a working private cloud, with far fewer moving parts than the OpenStack service list in the previous concept.

The difference is architectural. OpenNebula is centralized. The front-end holds the whole control plane: the oned daemon, the scheduler and an XML-RPC API, with Sunstone and the CLI sitting on top as clients. Hosts are hypervisor nodes, usually running a type 1 hypervisor such as KVM, grouped into clusters. Everything else plugs in through drivers. Storage drivers cover NFS, Ceph, local disks and others; network drivers cover Linux bridges, 802.1Q VLANs, VXLAN and Open vSwitch. Slide 62's "customized cluster" is this picture: the same front-end can drive hosts on your own physical servers, in an on-premises data center, or on bare metal rented from a public cloud, which is how OpenNebula supports hybrid and edge deployments.

Where it came from

OpenNebula is older than OpenStack. Ignacio M. Llorente and Rubén S. Montero started it in 2005 as a research project in the Distributed Systems Architecture group at Complutense University of Madrid, with the goal of managing virtual machines on distributed infrastructure. The first public release came in March 2008, under the Apache license. In 2010 the founders created a company, C12G Labs, to offer enterprise support; it was later renamed OpenNebula Systems.