OpenNebula: The Pragmatic Private Cloud

June 3, 2026 11 min read Virtualization & Containers

private-cloudopennebulavirtualizationkvminfrastructurehomelab

Contents

In the series intro we drew a line through the whole field with one test: does the platform have a placement scheduler — the component that, when you ask for a VM, decides on its own which physical host should run it? That test is what separates a cloud platform from a cluster manager. OpenStack passes it and makes you pay in operational complexity. Proxmox mostly fails it and is pleasant to run. OpenNebula is the interesting middle: it passes the test — it has a genuine scheduler, multi-tenancy, quotas, an API, and a web UI — and yet a single person can stand it up in an afternoon and keep it running without a platform team.

That combination is rare, and it is why OpenNebula is the right first stop in this series. If you read the intro and thought “I want a real cloud but I do not want to become an OpenStack operator,” this is very likely the platform you are looking for.

What OpenNebula actually is

OpenNebula is an open-source cloud management platform that has been around since 2008, originally out of a research project and now stewarded by OpenNebula Systems. Architecturally it is deliberately small. There is one front-end node running the core daemon (oned), a scheduler, the API endpoints, and the web UI. There are hypervisor nodes that run your workloads. The front-end talks to the nodes over SSH and a small agent footprint. That is essentially the whole picture.

Contrast that with OpenStack, where “the control plane” means Nova, Neutron, Cinder, Glance, Keystone, Placement, and a message bus and database underneath all of them, each a separate service to configure, monitor, and upgrade. OpenNebula folds the equivalent responsibilities into far fewer moving parts. You lose some of OpenStack’s extreme modularity and scale ceiling; you gain the ability to actually understand your own deployment.

As of mid-2026 the current line is OpenNebula 7.x (7.2.x), on a rapid release cadence that ships smaller increments more often. The headline modern pieces are:

FireEdge Sunstone — the new web GUI, rebuilt in React and Node.js, replacing the older Ruby-based Sunstone. It uses WebSockets for live resource state, and surfaces modern features like UEFI/Secure Boot and Prometheus integration directly in the interface.
Multi-hypervisor support — KVM is the default, but OpenNebula also drives LXC system containers, Firecracker microVMs, and VMware nodes. This is a real differentiator: OpenStack effectively ties you to KVM.
A cloud-edge continuum focus — much of OpenNebula’s recent direction is about managing not just one datacenter but distributed edge locations and bursting to public-cloud or bare-metal providers, with GPU passthrough for AI workloads as a first-class concern.

The scheduler: match-making, done simply

This is the feature the series cares about most, so it is worth being concrete about how OpenNebula does placement.

When you create a VM, you submit a template that describes what you want — CPU, memory, disks, networks — and says nothing about which host should run it. OpenNebula’s scheduler then runs a match-making pass:

Requirements filter every host and datastore against the VM’s hard requirements (SCHED_REQUIREMENTS / SCHED_DS_REQUIREMENTS). A host that cannot satisfy a constraint — not enough free memory, wrong CPU architecture, missing a required network or label — is eliminated outright.
Rank the surviving candidates with an expression (SCHED_RANK). The classic rank is a packing-vs-spreading choice: rank by FREE_MEMORY to spread load onto the emptiest host, or by -FREE_MEMORY (or RUNNING_VMS) to pack VMs tightly and leave whole hosts idle for power-down.
Place the VM on the top-ranked host and the chosen datastore, and dispatch.

   You submit a template (no host named):
     CPU=4  MEMORY=8192  NIC=tenant-net  DISK=ubuntu-2404

                 │
                 ▼
   ┌───────────────────────────────────────────────┐
   │  Scheduler match-making pass                   │
   │                                                │
   │  1. REQUIREMENTS  →  drop hosts that can't fit │
   │     (capacity? arch? network? label?)          │
   │                                                │
   │  2. RANK          →  score the survivors       │
   │     spread:  rank by FREE_MEMORY               │
   │     pack:    rank by -FREE_MEMORY              │
   │                                                │
   │  3. PLACE         →  top host + datastore       │
   └───────────────────────────────────────────────┘
                 │
                 ▼
   Deploys on host that scored highest (e.g. node-04)

It is not as elaborate as OpenStack Nova’s long chain of pluggable filters and weighers, and it does not, by default, continuously rebalance a running cluster the way VMware DRS does — placement happens at creation and at migration time, not as a constant background optimization. But it is a real scheduler that answers the “just pick the best machine for me” request, which is exactly the capability that puts OpenNebula on the cloud-platform side of the line. You can also pin affinity and anti-affinity (keep these VMs together, keep those apart) through host requirements and placement policies, and trigger live migrations that re-run the same match-making.

The honest framing: OpenNebula’s scheduler is sufficient and comprehensible. You will not spend a week tuning weigher coefficients. You will write a rank expression once and mostly forget about it.

Where OpenNebula is strong

It is genuinely manageable. This is the whole pitch. A minimal deployment is a front-end plus one or more KVM hosts. The front-end is a package install and a config file; adding a host is registering its SSH endpoint. There is no message queue to babysit, no constellation of services that must all agree on a shared secret. For a homelab or a small-to-medium business, the gap in operational burden between OpenNebula and OpenStack is enormous, and it shows up every single week, not just on install day.

The web UI is good and getting better. FireEdge Sunstone is a modern, reactive interface. Live state via WebSockets means you watch VMs change state in real time rather than refreshing. UEFI/Secure Boot, snapshots, network and storage management, and user/group administration are all there. For users who came up on vSphere’s Web Client, it feels familiar in the right ways.

Multi-tenancy and quotas are first-class. OpenNebula has a real users-and-groups model with VDCs (Virtual Data Centers) that carve a slice of the physical infrastructure and assign it to a group, plus per-user and per-group quotas on CPU, memory, storage, and network. This is one of the capabilities from the intro’s table that many homelab-oriented tools simply skip, and OpenNebula takes it seriously.

It layers onto what you already have. If you are already running KVM hosts, OpenNebula does not demand a greenfield rebuild — it manages existing libvirt/KVM nodes. Storage integrations are broad: local and shared filesystem datastores, Ceph RBD as a first-class backend (the natural pairing if you read the Ceph post), LVM, and NFS. Networking supports bridges, VLAN (802.1Q), VXLAN, and Open vSwitch, so you can start with simple bridged networking and grow into overlays.

Hypervisor flexibility. KVM for full VMs, LXC for lightweight system containers, Firecracker for fast microVMs, and VMware for nodes you have not migrated yet — all under one control plane. That range is unusual and genuinely useful during a migration, when you want one pane of glass over a mixed fleet.

Hybrid and edge bursting. OpenNebula can extend a private cloud out to public-cloud providers and to distributed edge sites, treating remote capacity as additional hosts. If your roadmap includes “datacenter plus a dozen small edge locations,” this is closer to OpenNebula’s home turf than to most alternatives'.

Where the edges show

No platform in this series is free of weaknesses, and pretending otherwise would make the comparison useless.

Smaller ecosystem and community. OpenStack has a vast gravitational field — vendors, integrations, training, Stack Overflow answers, and a hiring pool that has heard of it. OpenNebula’s community is healthy and the company is responsive, but it is an order of magnitude smaller. When you hit an unusual problem, there are fewer existing answers, and you will lean more on the official docs and the forum than on a sprawling third-party ecosystem.

Fewer turnkey integrations. Want a specific backup vendor, a particular SDN controller, a marketplace of pre-built appliances, a Terraform/OpenTofu provider with deep coverage? OpenStack’s API surface is so widely targeted that these usually exist. OpenNebula has an OpenTofu/Terraform provider and a growing marketplace, but the breadth is narrower. You will occasionally find that a tool integrates with OpenStack and CloudStack but not OpenNebula.

The networking model takes a mental adjustment. OpenNebula’s network model — virtual networks as address-range objects, with drivers for bridged/VLAN/VXLAN/OVS — is coherent once it clicks, but it does not map one-to-one onto the AWS VPC mental model the way Neutron’s routers/security-groups/floating-IPs do. Expect to spend time understanding address ranges and how leases work before tenant networking feels natural.

Polish gaps at the edges. The core paths are solid, but as you push into less-common features you can hit rough corners — a UI workflow that is clunkier than expected, a feature that exists in the CLI/API before it is fully surfaced in the GUI, documentation that assumes you already know the surrounding concept. None of this is disqualifying; it is the texture of a smaller project, and it is the price of the simplicity that makes OpenNebula attractive in the first place.

No continuous DRS-style rebalancing out of the box. As noted above, placement is decided at create and migrate time. If your mental model of “cloud” includes the cluster silently shuffling VMs all night to stay balanced, OpenNebula does not do that automatically the way VMware DRS does. You can script periodic rebalancing, but it is not a built-in continuous optimizer.

Who it is for

OpenNebula fits a recognizable shape of user:

The homelabber who outgrew Proxmox’s manual placement. You have three to six nodes, you are tired of choosing which one runs each VM, and you want self-service with real quotas — but standing up OpenStack feels like adopting a second job. OpenNebula is the natural step up.
The SMB or team that wants a private IaaS without a platform team. You need multi-tenancy, an API for automation, and a web portal for less-technical users, on a budget that does not include two full-time cloud operators.
The edge or AI-adjacent shop. Distributed sites, GPU passthrough for inference or training, and a mix of VMs and containers — areas where OpenNebula has invested heavily.

It is a worse fit if you need OpenStack-scale (thousands of nodes, the deepest possible RBAC, every networking feature under the sun and a vendor ecosystem to match), or if you want the absolute lightest-touch Linux-workload clustering with no multi-tenancy at all — for that, wait for the Incus/LXD post later in this series.

A realistic small deployment

A minimal but real OpenNebula topology looks like this:

   ┌────────────────────────┐
   │  Front-end node         │   oned + scheduler + FireEdge Sunstone + API
   │  (can be a small VM)     │   (the brain; not where workloads run)
   └───────────┬────────────┘
               │ SSH + drivers
        ┌──────┴───────┬───────────────┐
        ▼              ▼               ▼
   ┌─────────┐    ┌─────────┐     ┌─────────┐
   │ KVM host │    │ KVM host │     │ KVM host │   ← workloads run here
   │ node-01  │    │ node-02  │     │ node-03  │
   └────┬────┘    └────┬────┘     └────┬────┘
        └──────────────┴───────────────┘
                       │
                 ┌─────┴─────┐
                 │ Ceph RBD   │   shared storage → live migration + HA
                 │  cluster   │
                 └───────────┘

The front-end can be modest; it is a controller, not a workload host. The KVM nodes carry the VMs. Put shared storage underneath — Ceph RBD is the canonical choice — and you unlock live migration and high availability, because any host can run any VM when the disk lives on the shared cluster rather than on one node’s local disk.

Bringing it up, in broad strokes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# On the front-end: add the OpenNebula repo, then install the server + UI
sudo apt-get install opennebula opennebula-sunstone opennebula-fireedge

# Initialize and start the services
sudo systemctl enable --now opennebula opennebula-fireedge

# Register a KVM host so the scheduler can place VMs on it
onehost create node-01 -i kvm -v kvm
onehost create node-02 -i kvm -v kvm

# Add a Ceph datastore (image + system) so VMs share storage
onedatastore create ceph-images.conf   # TM_MAD=ceph, DS_MAD=ceph, POOL_NAME=one

# Define a virtual network (an address range tenants draw leases from)
onevnet create tenant-net.conf

# Create a VM from a template; note you never name a host —
# the scheduler picks one via match-making
onetemplate instantiate ubuntu-2404 --name web-01

The point of the last command is the whole thesis of this post: you described what you wanted, not where to run it, and the scheduler placed it. That is the cloud experience the intro described — reproduced on hardware you own, with a stack one person can actually operate.

Verdict

OpenNebula is the pragmatic private cloud. It clears the bar that matters — a real scheduler, real multi-tenancy, a real API and UI — while staying small enough that you do not need a dedicated team to keep it alive. Its weaknesses are the predictable cost of that smallness: a thinner ecosystem, fewer turnkey integrations, a networking model you have to learn, and occasional rough edges. For a very large fraction of people who want “AWS at home” and mean it, OpenNebula hits the best balance in this entire series of real cloud features against the effort to run them.

Next in the series we go the other direction on the architecture axis: Harvester, the cloud-native HCI platform that bets everything on Kubernetes — the most modern design in the field, and the one that asks you to inherit Kubernetes’ operational weight whether you wanted it or not.

Sources: