Architecture

OpenNebula is a single-daemon cloud management platform. Unlike OpenStack's distributed microservice approach, OpenNebula's core functionality runs in a single process (oned) with a modular driver framework for hypervisors, storage, networking, and authentication. This architectural simplicity is a key differentiator.

See also: infrastructure/opennebula/index, infrastructure/opennebula/architecture, infrastructure/opennebula/operations, infrastructure/opennebula/security

Component Overview

graph TD
    subgraph Frontend["Frontend Node"]
        ONED["oned<br/>(Core Daemon)"]
        SCHED["Scheduler<br/>(mm_sched)"]
        SUNSTONE["Sunstone<br/>(Web UI)"]
        FIREDGE["FireEdge<br/>(Guacamole Proxy)"]
        ONEFLOW["OneFlow<br/>(Service Orchestration)"]
        ONEGATE["OneGate<br/>(VM REST API)"]
        HEM["Hook Execution<br/>Manager (HEM)"]
    end

    subgraph Drivers["Driver Framework"]
        VM_DRV["VM Drivers<br/>(KVM, LXC, Firecracker)"]
        NET_DRV["Network Drivers<br/>(bridge, 802.1Q, OVSwitch, VXLAN)"]
        STO_DRV["Storage Drivers<br/>(FS, Ceph, LVM, vCenter)"]
        AUTH_DRV["Auth Drivers<br/>(SSH, LDAP, x509)"]
    end

    subgraph Hosts["Hypervisor Hosts"]
        KVM1["KVM Host 1"]
        KVM2["KVM Host 2"]
        LXC1["LXC Host"]
    end

    subgraph Datastores["Datastores"]
        SYS_DS["System DS<br/>(host-local SSH)"]
        IMG_DS["Image DS<br/>(shared/ceph)"]
        FILE_DS["File DS<br/>(kernel/initrd)"]
    end

    SUNSTONE --> ONED
    FIREDGE --> ONED
    ONEFLOW --> ONED
    ONEGATE --> ONED
    ONED --> SCHED
    ONED --> Drivers
    VM_DRV --> KVM1
    VM_DRV --> KVM2
    VM_DRV --> LXC1
    NET_DRV --> KVM1
    NET_DRV --> KVM2
    STO_DRV --> Datastores

Core Daemon: oned

oned is the central service of the OpenNebula platform. It is installed as the opennebula package and managed by the opennebula systemd service.

Key responsibilities:

• Manage cluster nodes (hosts), virtual networks, and datastores
• Manage users, groups, and Virtual Data Centers (VDCs)
• Manage VM lifecycle (create, deploy, migrate, terminate)
• Expose the XML-RPC API for all external access
• Coordinate with the scheduler for VM placement
• Execute drivers for hypervisor, storage, network, and authentication operations

The daemon configuration lives in /etc/one/oned.conf, which defines datastore types, supported drivers, monitoring intervals, and default VM settings.

Scheduler

The OpenNebula scheduling framework is a modular system responsible for resource allocation:

• Integrated with oned: The scheduler manager runs as part of the core daemon and requests placement plans from external scheduler processes
• Scheduler Plan Manager: Executes placement and optimization plans, deploying or migrating VMs
• External Schedulers: Generate placement and optimization plans using configurable policies

The scheduler allocates three resource types:

Resource	Purpose
Hosts	Determines which physical host runs each VM
System Datastores	Selects storage location for VM disk images
Virtual Networks	Assigns networks to VM interfaces (when set to auto mode)

Scheduling operations include:

• Initial VM placement: Based on capacity, compatibility, affinity rules, and constraints
• VM re-scheduling: On-demand re-placement triggered by admins or automation
• Cluster-wide load balancing: Generates optimization plans to distribute workloads per defined policies

Built-in schedulers include the Rank Scheduler (scores hosts with user-defined expressions) and the OpenNebula DRS (Distributed Resource Scheduler) for automated load balancing.

User Interfaces

Sunstone (Web UI)

Sunstone is the primary web management interface for OpenNebula. It communicates with oned via the XML-RPC API and provides:

• VM, template, image, and network management
• User and group administration
• Virtual Data Center (VDC) management
• Role-based views (cloud admin, group admin, end user)
• Cloud-init and contextualization support

Sunstone authentication supports its own login mechanism as well as integration with external identity providers.

FireEdge

FireEdge provides remote console access to VMs through a web browser. It integrates with Guacamole to offer:

• VNC, RDP, and SSH console access without client-side plugins
• Token-based session management
• Direct integration with Sunstone

OneFlow

OneFlow is a RESTful service for orchestrating multi-VM application stacks:

• Define services as groups of interconnected VMs with deployment dependencies
• Supports elasticity rules (auto-scale based on metrics)
• Manages VM startup ordering and shutdown sequencing
• Exposes a REST API independent of the core XML-RPC API

OneGate

OneGate is a RESTful service that enables running VMs to communicate with OpenNebula:

• VMs can pull contextualization data and push custom metrics
• Enables application-level monitoring inside the guest
• Useful for auto-scaling triggers in OneFlow

Driver Framework

OpenNebula uses a pluggable driver architecture to support heterogeneous infrastructure:

VM Drivers (Virtualization)

Driver	Description
KVM	Primary hypervisor; uses libvirt to manage QEMU/KVM guests
LXC	OS-level container virtualization (v7.2+ improved support)
Firecracker	MicroVM-based isolation for lightweight workloads
vCenter	VMware vCenter integration (primarily for migration)

Network Drivers

Driver	Description
bridge	Default Linux bridge networking
802.1Q	VLAN-tagged networking with per-VLAN bridges
OVSwitch	Open vSwitch integration
VXLAN	Overlay networking without switch configuration
AWS	Amazon VPC network integration
ebtables	Firewall rules at the Ethernet layer

Storage Drivers

Driver	Description
fs	Filesystem-based (shared via NFS, for example)
ceph	Ceph RBD integration for block storage
lvm	LVM volume groups
vcenter	VMware datastore integration
dummy	No transfer (useful for specialized setups)

Authentication Drivers

Driver	Description
core	Built-in user/password with SHA256 hashing
ssh	SSH key-based authentication
ldap	LDAP/Active Directory integration
x509	Client certificate authentication
server_cipher / server_x509	Service-to-service authentication

Datastores

OpenNebula uses three types of datastores:

Type	Purpose	Example
System DS	VM disk images and runtime files; typically host-local (SSH) or shared (NFS, Ceph)	/var/lib/one/datastores/0/
Image DS	Stores VM disk images (templates, ISOs); used for image registration and cloning	/var/lib/one/datastores/1/
File DS	Stores kernel, initrd, and context files	/var/lib/one/datastores/2/

The transfer from Image DS to System DS is handled by the storage driver. For example, Ceph drivers clone RBD images; SSH drivers copy files over SSH.

VM Lifecycle

stateDiagram-v2
    [*] --> Pending : onevm create
    Pending --> Hold : on hold
    Hold --> Pending : release
    Pending --> Prolog : scheduler assigns host
    Prolog --> Boot : transfer image to host
    Boot --> Running : guest OS boots
    Running --> Migrate : live migration
    Migrate --> Running : migration complete
    Running --> Saves : onevm suspend
    Saves --> Suspended : saved to disk
    Suspended --> Boot : onevm resume
    Running --> Shutdown : onevm shutdown
    Running --> Poweroff : onevm poweroff
    Poweroff --> Boot : onevm resume
    Shutdown --> Epilog : guest shuts down
    Epilog --> Done : cleanup
    Boot --> Failed : boot error
    Running --> Failed : monitor error
    Done --> [*]

System Interfaces

Interface	Protocol	Purpose
XML-RPC API	XML-RPC over HTTP	Primary API for all resource management
OneFlow API	REST (JSON)	Multi-VM service orchestration
OneGate API	REST (JSON)	VM-to-platform communication
Hooks (ZeroMQ)	Pub/Sub	Event-driven automation
Sunstone	HTTP/HTTPS	Web management interface
Prometheus Exporter	HTTP	Metrics export for monitoring

Language bindings are available for Ruby, Java, Go, and Python via the XML-RPC API.

Key File Locations

Path	Purpose
/etc/one/oned.conf	Core daemon configuration
/etc/one/sched.conf	Scheduler configuration
/etc/one/sunstone-server.conf	Sunstone web UI configuration
/etc/one/fireedge-server.conf	FireEdge console configuration
/etc/one/oneflow-server.conf	OneFlow service configuration
/var/lib/one/datastores/	Datastore directories
/var/lib/one/vms/	VM deployment files
/var/log/one/oned.log	Core daemon log
/var/log/one/sched.log	Scheduler log

References

• OpenNebula architecture
• oned configuration
• Scheduler overview
• System interfaces
• Authentication

---

How It Works

Internal mechanisms, VM lifecycle, the centralized daemon model, and the AI-powered DRS.

Centralized Architecture Model

Unlike OpenStack's distributed services, OpenNebula uses a centralized daemon model where oned is the single source of truth and orchestration. This dramatically simplifies operations, troubleshooting, and upgrades.

flowchart TB
    subgraph Frontend["Front-End Node"]
        ONED["oned\n(core daemon)"]
        Sched["Scheduler"]
        OneDRS["OneDRS\n(AI DRS)"]
        DB["MySQL / SQLite"]
        Sunstone["Sunstone UI"]
        OneFlow["OneFlow"]
        OneGate["OneGate"]
    end

    subgraph Host1["KVM Host 1"]
        Libvirt1["libvirtd"]
        VMs1["VMs"]
    end

    subgraph Host2["KVM Host 2"]
        Libvirt2["libvirtd"]
        VMs2["VMs"]
    end

    ONED -->|"SSH + drivers"| Host1
    ONED -->|"SSH + drivers"| Host2
    Sched --> ONED
    OneDRS --> ONED
    Sunstone --> ONED
    ONED --> DB

    style Frontend fill:#00758f,color:#fff

VM Provisioning Flow

sequenceDiagram
    participant User as User / Sunstone
    participant API as oned (XML-RPC / gRPC)
    participant DB as MySQL
    participant Sched as Scheduler
    participant Host as KVM Host

    User->>API: vm.allocate (template)
    API->>DB: Store VM record (PENDING)
    Sched->>DB: Read pending VMs
    Sched->>Sched: Match requirements → host
    Sched->>API: Deploy VM on Host X
    API->>Host: SSH: deploy script
    Host->>Host: Create libvirt domain
    Host->>Host: Attach disks, configure NICs
    Host->>Host: Start QEMU/KVM
    Host-->>API: VM RUNNING
    API->>DB: Update state → RUNNING

OneDRS (Distributed Resource Scheduler)

flowchart LR
    Metrics["Host Metrics\n(CPU, RAM, I/O)"] --> DRS["OneDRS Engine"]
    History["Historical Data\n(trends, patterns)"] --> DRS
    Policies["Placement Policies\n(packing, striping, load-aware)"] --> DRS
    DRS -->|"migration\nrecommendations"| ONED["oned"]
    ONED -->|"live migrate"| Hosts["KVM Hosts"]

    style DRS fill:#ff6f00,color:#fff

Storage Data Path

Driver	Access Pattern	Best For
Shared FS (NFS)	Front-end exports, hosts mount	Simple, live migration works natively
SSH	Front-end copies images via SSH	No shared storage needed
Ceph (RBD)	Direct RBD access from each host	Scale, performance, live migration
LVM	Local LVM on each host	Performance (local I/O)
iSCSI / FC	SAN target from each host	Enterprise, existing SAN infrastructure

Networking Model

flowchart TB
    subgraph VM["Virtual Machine"]
        VNIC["vNIC\n(virtio)"]
    end

    subgraph Host["Host Network"]
        Bridge["Linux Bridge\nor OVS"]
        VLAN["802.1Q VLAN\nor VXLAN"]
        PF["Physical NIC"]
    end

    VNIC --> Bridge --> VLAN --> PF

    subgraph SecurityGroups["Security"]
        FW["iptables / nftables\n(security groups)"]
    end

    Bridge --> FW

    style Host fill:#00758f,color:#fff

Sources

• OpenNebula Architecture
• OneDRS

---

Benchmarks

Scope

Performance characteristics, scaling limits, and resource consumption for OpenNebula.

VM Performance

Hypervisor	vCPU Overhead	Memory Overhead	Network
KVM	< 3%	100-200MB per VM	Near-native
LXC	< 1%	50MB per container	Native
Firecracker	< 1%	30MB per microVM	Near-native

Scaling Limits

Dimension	Single Frontend	HA (3 nodes)
VMs	2,000-5,000	10,000+
Hosts	200	500+
Networks	4,096 (VLAN)	16M (VXLAN)
Storage images	10,000+	10,000+

Scheduler Performance

VMs to Place	Scheduling Time
10	< 1s
100	1-5s
1,000	5-30s

Sourcing Status

Unsourced Performance Data

The performance numbers in this document are estimated from vendor documentation, community benchmarks, and engineering judgment. They do not represent controlled benchmarks with documented test conditions. Specific hardware configurations, software versions, and test methodologies were not recorded.

Use these figures as rough guidance only. For production capacity planning, run your own benchmarks against your specific workload and infrastructure.

Sources

• OpenNebula Documentation
• OpenNebula GitHub