Single Front-end Installation

This page describes how to install a complete OpenNebula Front-end from binary packages available in the software repositories configured in the previous section. We recommend using a Host with the supported operating system as installation from packages provides the best experience and is referenced in other places of this documentation. If there are no packages for your distribution, you might consider reading the Building from Source Code guide to build OpenNebula on your own.

Proceed with the following steps to get the fully-featured OpenNebula Front-end up.

Step 1. Configure the OpenNebula Repositories

Follow the OpenNebula Repositories guide and add software repositories for the OpenNebula edition you are going to deploy.

Step 2. Add Third Party Repositories

Not all OpenNebula dependencies are in base distribution repositories. On selected platforms below you need to enable third party repositories by running the following commands under privileged user (root):

AlmaLinux 8,9

yum -y install epel-release

RHEL 8

rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

RHEL 9

rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Step 3. Installing the Software

Available packages for OpenNebula clients, the Front-end and hypervisor nodes:

PackageDescription
opennebulaOpenNebula Daemon and Scheduler (EE comes with additional Enterprise Tools)
opennebula-toolsCommand Line Interface
opennebula-fireedgeNext-generation GUI FireEdge
opennebula-gateOneGate server which allows communication between VMs and OpenNebula
opennebula-flowOneFlow manages services and elasticity
opennebula-migrationDatabase migration tools
opennebula-node-kvmBase setup for KVM hyp. Node
opennebula-node-lxcBase setup for LXC hypervisor Node (not on RHEL 7)
opennebula-guacdProxy daemon for Guacamole
opennebula-rubygemsBundled Ruby gem dependencies
opennebula-libsShared Ruby libraries among various components
opennebula-commonShared content for OpenNebula packages
opennebula-common-onecfgHelpers for Configuration Management tool
rpm: opennebula-java

deb: libopennebula-java

deb: libopennebula-java-doc
Java OCA Bindings
python3-pyonePython 3 OCA Bindings

There are also packages with debugging symbols for some platforms, e.g., openenbula-debuginfo on AlmaLinux/RHEL and opennebula-dbgsym on Debian/Ubuntu. Other architecture-specific components might come with similarly named packages, please check your packaging database if necessary.

Install all OpenNebula Front-end components by executing the following commands under a privileged user:

AlmaLinux / RHEL

yum -y install opennebula opennebula-fireedge opennebula-gate opennebula-flow

Debian / Ubuntu

apt-get update
apt-get -y install opennebula opennebula-fireedge opennebula-gate opennebula-flow

Optional: Install dependencies for OpenNebula Edge Clusters provisioning

There are two main dependencies which needs to be installed on the FE for running provisioning.

  1. Terraform – is needed to provision resources on public cloud providers, download the binary as follows:
curl 'https://releases.hashicorp.com/terraform/0.14.7/terraform_0.14.7_linux_amd64.zip' | zcat >/usr/bin/terraform
chmod 0755 /usr/bin/terraform
  1. Ansible – is used to configure the provisioned resources (cloud or on-premise). Ansible system package is installed as a dependency of the OpenNebula provision package. However, for HCI provisioning including Ceph, the system-installed ansible version may not be sufficient as it requires ansible-core 2.15+. It is advised to use the latest Ubuntu for the FE if Ceph HCI provision is needed or to install ansible 2.15+ on the system and make it default for oneadmin user.

Step 4. Enabling MySQL/MariaDB (Optional)

You can skip this step if you want to deploy OpenNebula as quickly as possible for evaluation.

If you are deploying Front-end for production/serious use, make sure you read the Database Setup guide and select the suitable database backend. Although it is possible to switch from (default) SQLite to MySQL/MariaDB backend later, it’s not easy and straightforward, so we suggest to deploy and use MySQL/MariaDB backend from the very beginning.

Step 5. Configuring OpenNebula

OpenNebula Daemon

OpenNebula’s initial deployment on first usage creates a user oneadmin inside the OpenNebula (not to be confused with system user oneadmin in the Front-end operating system!) based on a randomly generated password read from /var/lib/one/.one/one_auth. To set your own user password from the very beginning, proceed with the following steps before starting the services:

  1. Log in as the oneadmin system user with this command:
sudo -u oneadmin /bin/sh
  1. Create file /var/lib/one/.one/one_auth with initial password in the format oneadmin:<password>
echo 'oneadmin:changeme123' > /var/lib/one/.one/one_auth

Check how to change oneadmin password for already running services.

FireEdge

OpenNebula FireEdge is the next-generation web UI server that replaces the legacy Ruby Sunstone. It provides the Sunstone GUI, including additional functionality provided via Guacamole. It is installed and configured by default.

OneGate (Optional)

The OneGate server allows communication between VMs and OpenNebula. It’s optional and not required for basic functionality but is essential for multi-VM services orchestrated by OneFlow server below. The configuration is two-phase: configure the OneGate server to listen for the connections from outside the Front-end and configure the OpenNebula Daemon with OneGate endpoint passed to the Virtual Machines. Neither or both must be done.

  1. To configure OneGate, edit /etc/one/onegate-server.conf and update the :host parameter with service listening address accordingly. For example, use 0.0.0.0 to work on all configured network interfaces on the Front-end:
:host: 0.0.0.0
  1. To configure OpenNebula Daemon, edit /etc/one/oned.conf and set the ONEGATE_ENDPOINT with the URL and port of your OneGate server (domain or IP-based). The endpoint address must be reachable directly from your future Virtual Machines. You need to decide which virtual networks and addresses will be used in your cloud. For example:
ONEGATE_ENDPOINT="http://one.example.com:5030"

If you are reconfiguring already running services at a later point, don’t forget to restart them to apply the changes.

OneFlow (Optional)

The OneFlow server orchestrates the services and multi-VM deployments. While for most cases the default configuration fits well, you might need to reconfigure the service to be able to control the OneFlow remotely over API. Edit the /etc/one/oneflow-server.conf and update :host: parameter with service listening address accordingly. For example, use 0.0.0.0 to work on all configured network interfaces on the Front-end:

:host: 0.0.0.0

If you are reconfiguring already running services at a later point, don’t forget to restart them to apply the changes.

Step 6. Starting and Managing OpenNebula Services

The complete list of operating system services provided by OpenNebula:

ServiceDescriptionAuto-Starts With
opennebulaMain OpenNebula Daemon (oned), XML-RPC API endpoint
opennebula-hemHook Execution Serviceopennebula
opennebula-fireedgeNext-generation GUI server FireEdge
opennebula-gateOneGate Server for communication between VMs and OpenNebula
opennebula-flowOneFlow Server for multi-VM services
opennebula-guacdGuacamole Proxy Daemonopennebula-fireedge
opennebula-showbackService for periodic recalculation of showbackopennebula
opennebula-ssh-agentDedicated SSH agent for OpenNebula Daemonopennebula
opennebula-ssh-socks-cleanerPeriodic cleaner of SSH persistent connectionsopennebula

You are ready to start all OpenNebula services with the following command (NOTE: you might want to remove the services from the command arguments if you skipped their configuration steps above):

systemctl start opennebula opennebula-fireedge opennebula-gate opennebula-flow

Other OpenNebula services might be started as a dependency but you don’t need to care about them unless they need to be explicitly restarted or stopped. To start these services automatically on server boot, it’s necessary to enable them by the following command:

systemctl enable opennebula opennebula-fireedge opennebula-gate opennebula-flow

Step 7. Verifying the Installation

After OpenNebula is started for the first time, you should check that the commands can connect to the OpenNebula Daemon. You can do this in the Linux CLI or the graphical user interface Sunstone.

Linux CLI

In the Front-end, run the following command as oneadmin system user and find a similar output:

$ oneuser show
USER 0 INFORMATION
ID              : 0
NAME            : oneadmin
GROUP           : oneadmin
PASSWORD        : 3bc15c8aae3e4124dd409035f32ea2fd6835efc9
AUTH_DRIVER     : core
ENABLED         : Yes

USER TEMPLATE
TOKEN_PASSWORD="ec21d27e2fe4f9ed08a396cbd47b08b8e0a4ca3c"

RESOURCE USAGE & QUOTAS

If you get an error message then the OpenNebula Daemon could not be started properly:

$ oneuser show
Failed to open TCP connection to localhost:2633 (Connection refused - connect(2) for "localhost" port 2633)

To check for errors, you can search in the main OpenNebula Daemon log file, /var/log/one/oned.log. Check for any error messages marked with [E].

FireEdge

Now you can try to log in through the Sunstone GUI and Provision GUI. To do so, point your browser to http://<frontend_address>:2616/fireedge/sunstone to access Sunstone and point your browser to http://<frontend_address>:2616/fireedge/provision to access Provision. You should get to the login page in both cases. The access user is oneadmin and initial (or customized) password is the one from the file /var/lib/one/.one/one_auth on your Front-end.

sunstone_login

In case of problems, you can investigate the OpenNebula logs in /var/log/one and check file /var/log/one/fireedge.log.

Directory Structure

The following table lists various significant directories on your OpenNebula Front-end:

PathDescription
/etc/one/Configuration files
/var/log/one/Log files, e.g. oned.log, fireedge.log and <vmid>.log
/var/lib/one/oneadmin home directory
/var/lib/one/datastores/<dsid>/Storage for the datastores
/var/lib/one/vms/<vmid>/Action files for VMs (deployment file, transfer manager scripts, etc…)
/var/lib/one/.one/one_authoneadmin credentials
/var/lib/one/remotes/Probes and scripts that will be synced to the Hosts
/var/lib/one/remotes/etcConfiguration files for probes and scripts
/var/lib/one/remotes/hooks/Hook scripts
/var/lib/one/remotes/vmm/Virtual Machine Manager Driver scripts
/var/lib/one/remotes/auth/Authentication Driver scripts
/var/lib/one/remotes/im/Information Manager (monitoring) Driver scripts
/var/lib/one/remotes/market/Marketplace Driver scripts
/var/lib/one/remotes/datastore/Datastore Driver scripts
/var/lib/one/remotes/vnm/Networking Driver scripts
/var/lib/one/remotes/tm/Transfer Manager Driver scripts

Firewall Configuration

The list below shows the ports used by OpenNebula. These ports need to be open for OpenNebula to work properly:

PortDescription
22Front-end host SSH server
2474OneFlow server
2616Next-generation GUI server FireEdge
2633Main OpenNebula Daemon (oned), XML-RPC API endpoint
4124Monitoring daemon (both TCP/UDP)
5030OneGate server
29876noVNC Proxy Server
5900+VNC Server ports on Hosts for VMs. See VNC_PORTS
49152-49215Host-Host port communication required for KVM live migrations

OpenNebula connects to the hypervisor nodes over SSH (port 22). Additionally, the main OpenNebula Daemon (oned) may connect to various remote Marketplace servers to get a list of available appliances, e.g.:

  • OpenNebula Marketplace (https://marketplace.opennebula.io/)
  • Linux Containers Marketplace (https://images.linuxcontainers.org/)

You should open the outgoing connections to these services.

Step 8. Stop and Restart Services (Optional)

To stop, start, or restart any of the listed individual services, follow the examples below for a selected service:

systemctl stop opennebula
systemctl start opennebula
systemctl restart opennebula
systemctl try-restart opennebula

Use following command to stop all OpenNebula services:

systemctl stop opennebula opennebula-hem opennebula-fireedge \
    opennebula-gate opennebula-flow opennebula-guacd \
    opennebula-novnc opennebula-showback.timer \
    opennebula-ssh-agent opennebula-ssh-socks-cleaner.timer

Use the following command to restart all already running OpenNebula services:

systemctl try-restart opennebula-hem opennebula-fireedge \
    opennebula-gate opennebula-flow opennebula-guacd \
    opennebula-novnc opennebula-ssh-agent

Learn more about Managing Services with Systemd.

In production environments the services should be stopped in a specific order and with extra manual safety checks:

  1. Stop opennebula-fireedge to disable GUI access to users.
  2. Stop openenbula-flow to disable unattended multi-VM options.
  3. Check and wait until there are no active operations with VMs and images.
  4. Stop opennebula and rest services.

Step 9. Next Steps

Now that you have successfully started your OpenNebula services, you can continue with adding content to your cloud. Add hypervisor nodes, storage, and virtual networks. Or you can provision users with groups and permissions, images, define and run Virtual Machines.

Continue with the following guides: