OpenNebula Community Edition on Ubuntu 24.04 LTS on Azure

This image ships OpenNebula Community Edition 7.2 on Ubuntu 24.04 LTS as a cloud management front-end, installed from the OpenNebula project's official Community Edition apt repository and pinned to a known release. The core daemon, the scheduler, the FireEdge Sunstone web console, OneFlow and OneGate are all installed, configured and running the moment the machine finishes its first boot.

OpenNebula is an open source platform for building and running private clouds and managed virtual infrastructure. It holds the model of an entire estate — virtual machines, virtual networks, images, templates, users, groups and quotas — and schedules workloads onto the hypervisor capacity registered with it. You drive it from a web console, a complete command line toolset, or an XML-RPC API.

What this appliance is, and what it is not

Read this section before you deploy. It is the difference between an appliance that does what you think it does and one that quietly does not.

This image is an OpenNebula front-end (management) node. It is the control plane: it runs oned, the scheduler, the Sunstone web console, OneFlow and OneGate. It stores and manages the definitions of your virtual machines, networks, images and templates, handles users, groups, quotas and access control, and exposes the API and console you administer the estate through.

This image is not a hypervisor host. It does not run your virtual machines itself. OpenNebula separates these two roles deliberately, and packages them separately upstream: the front-end comes from the opennebula package (installed here), while hypervisor hosts come from opennebula-node-kvm or opennebula-node-lxc (not installed here, by design). To actually run workloads you register one or more of your own KVM or LXC hosts against this front-end with onehost create — that is covered in section 7, and it is the standard OpenNebula topology for any deployment beyond a single laptop.

Why it is built this way. Running KVM guests inside a cloud virtual machine requires nested virtualisation, which the general purpose VM sizes this image is validated on do not provide. Rather than ship an image that appears to be a self contained hypervisor and then fails the first time you try to start a virtual machine on it, this image is an honest, fully functional control plane, and the guide tells you exactly what to attach to it.

So this appliance is the right choice when you want a managed OpenNebula control plane for hypervisor hardware you already have or intend to provision — on-premises servers, bare metal in a colocation facility, or dedicated hosts. It is not a way to run virtual machines inside a single cloud VM.

What makes this image different

No shared credential, ever. Upstream, OpenNebula generates its oneadmin password when the package is installed and creates its internal serveradmin account the first time the daemon starts. In a shared machine image both of those, plus the console's session signing key and the front-end's SSH private key, would be baked in at build time and would be identical on every instance — every customer would hold the keys to every other customer's cloud controller.

This image never ships any of them. The build removes the bootstrapped database, every credential file, the console session key and the build-time SSH keypair, and closes a systemd condition gate so the daemon physically cannot start without them. On the first boot of each instance a unique administrator password, a unique internal server password, a fresh console signing key and a fresh SSH keypair are generated, and the database is bootstrapped with the new password — so the build-time credential exists nowhere in the image at all.

Secure by default. The XML-RPC API is bound to loopback, so the control plane API is not exposed to the internet unless you deliberately open it (section 8). The web console is the public listener and requires a login. Every OpenNebula API call is authenticated; there is no anonymous mode.

Proven, not assumed. Every image is checked with an authenticated control plane round trip that creates a virtual network, reads back the exact values it set, confirms it in the pool listing, deletes it and confirms the deletion — and separately proves that a wrong password is refused on both the CLI and the raw API.

1. Deploy the virtual machine

Deploy the image from the Azure Marketplace. A Standard_B2s (2 vCPU, 4 GB) is enough for a front-end managing a modest estate; move to a Standard_B2ms or Standard_D2s_v5 for larger estates or many concurrent console users.

In the networking step, allow inbound TCP 22 (SSH) and 2616 (the Sunstone web console) from your own address ranges. Do not open 2616 to the whole internet unless you intend the console to be public.

2. Connect and read the per-VM credentials

Every instance generates its own credentials on first boot and writes them to a root-only file.

sudo cat /root/opennebula-credentials.txt

You will see the console URL, the oneadmin username and this instance's unique password, and the internal serveradmin password. The file is 0600 root:root, and the CLI credential lives separately at /var/lib/one/.one/one_auth, owned by oneadmin:

sudo ls -l /root/opennebula-credentials.txt /var/lib/one/.one/one_auth

If the file still says placeholder, rotated at first boot, first boot has not finished yet — give it a moment and see section 9.

3. Confirm the front-end is healthy

Check the version and that the services are running:

dpkg-query -W -f='${Version}\n' opennebula
systemctl is-active opennebula opennebula-fireedge opennebula-flow opennebula-gate

All four should report active. Confirm the two listeners — the console on 2616 and the API on loopback 2633:

ss -ltn | grep -E ':2633|:2616'

Now prove the control plane genuinely works, rather than merely that the process is up. This image ships a self check that performs a real authenticated round trip:

sudo /usr/local/sbin/opennebula-roundtrip-check.sh

It ends with ROUNDTRIP_SUCCESS.

This matters because a running process is not proof of a working cloud controller: the one* tools can return successfully while the daemon is still starting, and the console will happily serve a login page while the backend behind it is dead. The check gates on an authenticated call that returns real data.

4. Sign in to the Sunstone web console

Open the console URL from your credentials file in a browser:

http://<your-vm-public-ip>:2616/

Sign in as oneadmin with this instance's password.

The dashboard summarises the estate — virtual machines, templates, images and virtual networks.

5. Use the command line

The CLI runs as the oneadmin system user, which reads its credential from /var/lib/one/.one/one_auth:

sudo -u oneadmin oneuser show
sudo -u oneadmin onevnet list
sudo -u oneadmin onetemplate list
sudo -u oneadmin onehost list

onehost list is empty on a fresh front-end — that is expected, and section 7 is where you change it.

Set ONE_PAGER=cat in any script that calls these tools; the default pager is interactive and will block an unattended run.

6. Create a virtual network and a template

Define a virtual network. This is a control plane object: it records the bridge, the address range and the driver that hypervisor hosts will use when a VM is attached to it.

cat > /tmp/service-net.tmpl <<'EOF'
NAME    = "service-net"
VN_MAD  = "dummy"
BRIDGE  = "br0"
AR      = [ TYPE = "IP4", IP = "10.10.0.10", SIZE = "100" ]
EOF
sudo -u oneadmin onevnet create /tmp/service-net.tmpl
sudo -u oneadmin onevnet list

Read back what you created, to confirm the values were stored:

sudo -u oneadmin onevnet show service-net

Use VN_MAD = "bridge" (with a bridge that exists on your hosts) for networks that will carry real traffic; dummy is used above so the example is safe to run before any host is registered.

The same networks appear in the console under Networks → Virtual Networks:

Now define a VM template — the reusable specification a virtual machine is instantiated from:

cat > /tmp/web.tmpl <<'EOF'
NAME        = "ubuntu-web-server"
CPU         = "1"
VCPU        = "2"
MEMORY      = "2048"
DESCRIPTION = "Ubuntu web server template"
EOF
sudo -u oneadmin onetemplate create /tmp/web.tmpl
sudo -u oneadmin onetemplate show ubuntu-web-server

Templates and networks can be created now; they will be instantiated onto whichever hypervisor hosts you register next.

7. Register your hypervisor hosts

This is the step that turns the control plane into a working cloud. On each machine that will run virtual machines — a physical server, or any host with hardware virtualisation available — install the OpenNebula node package for your hypervisor and register it here.

The console's Infrastructure → Hosts view is where registered hosts appear. On a fresh front-end it is empty:

The front-end reaches its hosts over SSH as the oneadmin user, using the keypair this instance generated on first boot. Copy its public key to each host's oneadmin account:

sudo cat /var/lib/one/.ssh/id_rsa.pub

Then register the host from the front-end:

sudo -u oneadmin onehost create host01 --im kvm --vm kvm
sudo -u oneadmin onehost list

A correctly registered host moves to the ON state once the front-end has polled it. From that point the scheduler can place virtual machines on it, and onetemplate instantiate will actually start workloads. Full host installation instructions are in the OpenNebula documentation under KVM Node Installation.

8. The XML-RPC API

Every OpenNebula operation is available over XML-RPC, and every call carries a session string of user:password. The API is bound to loopback in this image, so from the instance itself:

curl -s -X POST http://127.0.0.1:2633/RPC2 \
  -H 'Content-Type: text/xml' \
  --data-binary '<?xml version="1.0"?><methodCall><methodName>one.vnpool.info</methodName><params><param><value><string>oneadmin:<ONEADMIN_PASSWORD></string></value></param><param><value><i4>-2</i4></value></param><param><value><i4>-1</i4></value></param><param><value><i4>-1</i4></value></param></params></methodCall>' \
  | head -c 300

A successful call returns <boolean>1</boolean> followed by the payload. A wrong password returns <boolean>0</boolean> and an authentication error — there is no unauthenticated access to this API.

To use the API from outside the instance, prefer an SSH tunnel rather than exposing the port:

ssh -L 2633:127.0.0.1:2633 azureuser@<your-vm-public-ip>

If you genuinely need the API reachable on the network, set LISTEN_ADDRESS = "0.0.0.0" in /etc/one/oned.conf, restart with systemctl restart opennebula, and restrict access with an Azure network security group rule. Treat that as opening your cloud controller to whatever can reach it.

9. First boot and troubleshooting

On the very first boot, opennebula-firstboot.service generates this instance's credentials, bootstraps the database with them and starts the stack. It runs once and leaves a marker behind.

systemctl status opennebula-firstboot.service --no-pager
ls -l /var/lib/cloudimg/

• The credentials file still says placeholder. First boot has not completed. Check journalctl -u opennebula-firstboot.service.
• The services are inactive and will not start. They are gated on /var/lib/cloudimg/opennebula-bootstrap-ready, which first boot creates after writing credentials. If it is missing, first boot did not finish; read its journal rather than starting the services by hand, because starting them without credentials in place is exactly what the gate prevents.
• The console loads but nothing works. Run the round trip check in section 3 — it distinguishes a healthy console from one whose backend is down.
• The API refuses your password. The CLI reads /var/lib/one/.one/one_auth; the console uses the same oneadmin password from your credentials file. If you changed it with oneuser passwd, update one_auth to match.

Logs live in /var/log/one/, and journalctl -u opennebula covers the daemon itself.

10. Keeping the image current

The OpenNebula packages are pinned to the release this image was built and validated against, so an unattended upgrade cannot move the appliance onto a different series underneath you. Ubuntu security updates are applied normally through unattended upgrades. To move to a newer OpenNebula release, read the project's upgrade notes first — a front-end upgrade includes a database migration — then remove the pin at /etc/apt/preferences.d/opennebula.

11. Licensing

OpenNebula Community Edition is distributed by OpenNebula Systems under the Apache License 2.0, with no additional rider or exception. Every package installed here comes from the project's official Community Edition repository and is built as Community Edition; no subscription or token is required. The supporting components are the conventional open source stack (Ruby, SQLite, Node.js, libxml2) from that repository and the Ubuntu archive.

OpenNebula also offers a separately licensed Enterprise Edition. This image contains only Community Edition. cloudimg is not affiliated with OpenNebula Systems; the OpenNebula name and logo are used to identify the software this image contains.

Support

This image is published and supported by cloudimg, with 24/7 support. Please raise questions through your Azure Marketplace support channel.