Installing the Software 3.0

This page will show you how to install OpenNebula from the binary packages. Please read the Planning the Installation guide before you proceed.

inlinetoc

Package Installation (Front-End)

Visit the software menu to download the latest package for your distribution. OpenNebula may be included in your official distribution package repositories, but you should check if it is the latest version and download it from our page instead.

Then proceed to install the packages with the corresponding package manager for your distribution or head to Building from Source Code guide if there are no packages for it.

CentOS platform notes

Before installing:

  • activate the EPEL repo.

openSUSE platform notes

Before installing:

Installation Layout (Front-End)

After installing the opennebula packages the following directory structure will be used

Ruby Libraries Requirements (Front-End)

Some OpenNebula components need ruby libraries. OpenNebula provides a script that installs the required gems as well as some development libraries packages needed.

As root execute: <xterm> # /usr/share/one/install_gems </xterm>

The previous script is prepared to detect common linux distributions and install the required libraries. If it fails to find the packages needed in your system, manually install these libraries:

  • sqlite3 development library
  • mysql client development library
  • curl development library
  • libxml2 and libxslt development libraries
  • ruby development library
  • expat development library

If you want to install only a set of gems for an specific component read Building from Source Code where it is explained in more depth.

The following is required for the Front-End:

  • ruby >= 1.8.7

Requirements (Hosts)

You don't need to install any OpenNebula component in your hosts. These are the only requirements in the host machines:

  • ssh server running
  • hypervisor working properly configured
  • ruby >= 1.8.7

User & Group (Unix Accounts) (Front-End & Hosts)

The OpenNebula package installation creates a new user and group named oneadmin in the front-end. This account will be used to run the OpenNebula services and to do regular administration and maintenance tasks. That means that you eventually need to login as that user or to use the “sudo -u oneadmin” method.

The hosts need also this user created and configured. Make sure you change the uid and gid by the ones you have in the frontend.

  • Get the user and group id of oneadmin. This id will be used later to create users in the hosts with the same id. In the front-end, execute as oneadmin:

<xterm> $ id oneadmin uid=1001(oneadmin) gid=1001(cloud) groups=1001(cloud) </xterm> In this case the user id will be 1001 and group also 1001.

Then log as root in your hosts and follow these steps:

  • Create the oneadmin group. Make sure that its id is the same as in the frontend. In this example 1001:

<xterm> # groupadd –gid 1001 oneadmin </xterm>

  • Create the oneadmin account, we will use the OpenNebula var directory as the home directory for this user.

<xterm> # useradd –uid 1001 -g oneadmin -d /var/lib/one oneadmin </xterm>

:!: You can use any other method to make a common oneadmin group and account in the nodes, for example NIS.

Secure Shell Access (Front-End)

You need to create ssh keys for the oneadmin user and configure the host machines so it can connect to them using ssh without need for a password.

:!: This section assumes that the directory /var/lib/one is shared by the front-end and all the hosts (check the shared FS section for hints about using NFS).

Follow these steps in the front-end:

  • Generate oneadmin ssh keys:

<xterm> $ ssh-keygen </xterm> When prompted for password press enter so the private key is not encrypted.

  • Append the public key to ~/.ssh/authorized_keys to let oneadmin user log without the need to type a password.

<xterm> $ cat ~/.ssh/id_rsa.pub » ~/.ssh/authorized_keys </xterm>

  • Many distributions (RHEL/CentOS for example) have permission requirements for the public key authentication to work:

<xterm> $ chmod 700 ~/.ssh/ $ chmod 600 ~/.ssh/id_dsa.pub $ chmod 600 ~/.ssh/id_dsa $ chmod 600 ~/.ssh/authorized_keys </xterm>

  • Tell ssh client to not ask before adding hosts to known_hosts file. This is configured into ~/.ssh/config, see man ssh_config for a complete reference.:

<xterm> $ cat ~/.ssh/config Host *

  StrictHostKeyChecking no

</xterm>

  • Finally, check that the sshd daemon is running in the hosts. Also remove any Banner option from the sshd_config file in the hosts.

If you exported /var/lib/one, then oneadmin should be able to log in the hosts without being prompt for a password.

:!: If you are not going to export /var/lib/one via a shared FS, such as NFS, then you must copy the front-end /var/lib/one/.ssh directory to each one of the hosts; in the same path.

Starting OpenNebula (Front-End)

Log in as the oneadmin user follow these steps:

  • Set oneadmin's OpenNebula credentials (username and password) adding the following to ~/.one/one_auth (change password for the desired password):

<xterm> $ mkdir ~/.one $ echo “oneadmin:password” > ~/.one/one_auth $ chmod 600 ~/.one/one_auth </xterm>

  • You are ready to start the OpenNebula daemons:

<xterm> $ one start </xterm>

:!: Remember to always start OpenNebula as oneadmin!

Verifying the Installation

After OpenNebula is started for the first time, you should check that the commands can connect to the OpenNebula daemon. In the front-end, run as oneadmin the command onevm:

<xterm> $ onevm list ID USER GROUP NAME STAT CPU MEM HOSTNAME TIME </xterm>

If instead of an empty list of VMs you get an error message, then the OpenNebula daemon could not be started properly: <xterm> $ onevm list Connection refused - connect(2) </xterm>

The OpenNebula logs are located in /var/log/one, you should have at least the files oned.log and sched.log, the core and scheduler logs. Check oned.log for any error messages, marked with [E].

:!: The first time OpenNebula is started, it performs some SQL queries to check if the DB exists and if it needs a bootstrap. You will have two error messages in your log similar to these ones, and can be ignored:

[ONE][I]: Checking database version.
[ONE][E]: (..) error: no such table: db_versioning
[ONE][E]: (..) error: no such table: user_pool
[ONE][I]: Bootstraping OpenNebula database.

Next Steps

Now that OpenNebula is installed, follow the Basic Configuration guide to configure the software for you infrastructure.

OpenNebula comes with additional components that can be optionally started. Read the following guides to know which other components are included with the distribution: