Installing the Software 4.4

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

inlinetoc

1. Front-end Installation

THIS IS RECOMMENDED (FROM OUR SITE FOR STABILITY…) and we offer two…To install OpenNebula you can add our package repositories as it is described bellow, or visit the software menu to download the latest package for your Linux distribution.

Do not forget that we offer Quickstarts for: - -

OpenNebula may be also included in your official distribution package repositories, but you should check if it is the latest version and download it from our page instead (recommended).

IF THERE IS NO PACKAGES for your distribution or head to Building from Source Code guide if there are no packages for it.

1.1. Installing on CentOS/RHEL

Before installing:

  • Activate the EPEL repo.

There are packages for the front-end, distributed in the various components that conform OpenNebula, and packages for the virtualization host. See the CentOS/RHEL annex for a description of this packages.

To install a CentOS/RHEL OpenNebula front-end with packages from our repository, execute the following as root:

<xterm> # cat << EOT > /etc/yum.repos.d/opennebula.repo [opennebula] name=opennebula baseurl=http://downloads.opennebula.org/repo/CentOS/6/stable/$basearch enabled=1 gpgcheck=0 EOT # yum install opennebula-server opennebula-sunstone opennebula-ruby </xterm>

To install a CentOS/RHEL OpenNebula front-end with packages downloaded from our page, untar the tar.gz in the front-end and run:

<xterm> # tar xvzf CentOS-6-opennebula-<OpenNebula Version>.tar.gz # sudo yum localinstall opennebula-server opennebula-sunstone opennebula-ruby </xterm>

CentOS/RHEL package description

These are the packages available for this distribution:

  • opennebula-server: main OpenNebula daemon, scheduler, etc
  • opennebula-sunstone: OpenNebula Sunstone, EC2, OCCI
  • opennebula-ozones: OpenNebula OZones
  • opennebula-ruby: Ruby Bindings
  • opennebula-java: Java Bindings
  • opennebula-gate: Gate server that enables communication between VMs and OpenNebula
  • opennebula-flow: Manages services and elasticity
  • opennebula-node-kvm: meta-package that installs the oneadmin user, libvirt and kvm

1.2. Installing on openSUSE

Before installing:

<xterm> # zypper ar -f -n packman http://packman.inode.at/suse/openSUSE_12.3 packman </xterm>

To install an openSUSE OpenNebula front-end with packages from our repository, execute the following as root:

<xterm> # zypper addrepo --no-gpgcheck --refresh -t YUM http://downloads.opennebula.org/repo/openSUSE/12.3/stable/x86_64 opennebula # zypper refresh # zypper install opennebula opennebula-sunstone </xterm>

To install downloaded packages in this distro use the command, execute the following as root:

<xterm> # tar xvzf openSUSE-12.3-<OpenNebula version>.tar.gz # zypper install opennebula opennebula-sunstone </xterm>

After installation you need to manually create /var/lib/one/.one/one_auth with the following contents:

<xterm> oneadmin:<password> </xterm>

openSUSE package description

These are the packages available for this distribution:
  • opennebula: main OpenNebula binaries
  • opennebula-devel: Examples, manpages and install_gems (depends on opennebula)
  • opennebula-zones: OpenNebula OZones (depends on opennebula)
  • opennebula-sunstone: OpenNebula Sunstone (depends on opennebula)

1.3. Installing on Debian/Ubuntu

Also the JSON ruby library packaged with Debian 6 is not compatible with ozones. To make it work a new gem should be installed and the old one disabled. You can do so executing these commands:

<xterm> $ sudo gem install json $ sudo mv /usr/lib/ruby/1.8/json.rb /usr/lib/ruby/1.8/json.rb.no </xterm>

To install OpenNebula on a Debian/Ubuntu front-end from packages from our repositories execute as root:

<xterm> # wget http://downloads.opennebula.org/repo/Debian/repo.key # apt-key add repo.key </xterm>

Debian <xterm> # echo "deb http://downloads/opennebula.org/repo/Debian/7 stable opennebula" > /etc/apt/sources.list.d/opennebula.list </xterm>

Ubuntu 12.04 <xterm> # echo "deb http://downloads.opennebula.org/repo/Ubuntu/12.04 stable opennebula" > /etc/apt/sources.list.d/opennebula.list </xterm>

Ubuntu 13.04 <xterm> # echo "deb http://downloads.opennebula.org/repo/Ubuntu/13.04 stable opennebula" > /etc/apt/sources.list.d/opennebula.list </xterm>

To install the packages on a Debian/Ubuntu front-end: <xterm> # apt-get update # apt-get install opennebula opennebula-sunstone </xterm>

To install downloaded packages on a Debian/ubuntu front-end use the following commands as root:

<xterm> $ sudo dpkg -i opennebula opennebula-sunstone $ sudo apt-get install -f </xterm>

Debian/Ubuntu package description

These are the packages available for these distributions:

  • opennebula-common: provides the user and common files
  • libopennebula-ruby: all ruby libraries
  • opennebula-node: prepares a node as an opennebula-node
  • opennebula-sunstone: OpenNebula Sunstone Web Interface
  • opennebula-tools: Command Line interface
  • opennebula-gate: Gate server that enables communication between VMs and OpenNebula
  • opennebula-flow: Manages services and elasticity
  • opennebula: OpenNebula Daemon

1.4. Installing on ArchLinux

OpenNebula is available at the Arch User Repository (AUR), please check the opennebula package page.

1.5. Installing on Gentoo

You need to compile the xmlrpc-c package with threads support, as:

  USE="threads" emerge xmlrpc-c

2. Ruby Runtime Installation

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 packages:

  • sqlite3 development library
  • mysql client development library
  • curl development library
  • libxml2 and libxslt development libraries
  • ruby development library
  • gcc and g++
  • make

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.

3. Starting OpenNebula

Log in as the oneadmin user follow these steps:

  • If you installed from packages, you should have the '~/.one/one_auth' file created with a randomly-generated password. Otherwise, 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>

:!: This will set the oneadmin password on the first boot. From that point, you must use the 'oneuser passwd' command to change oneadmin's password.

  • You are ready to start the OpenNebula daemons:

<xterm> $ one start </xterm>

:!: Remember to always start OpenNebula as oneadmin!

4. 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.

After installing the opennebula packages in the front-end the following directory structure will be used

5. Node Installation

5.1. Installing on CentOS/RHEL

When the front-end is installed and verified, it is time to install the packages for the nodes if you are using KVM. To install a CentOS/RHEL OpenNebula front-end with packages from our repository, execute the following as root:

<xterm> # sudo yum localinstall opennebula-node-kvm </xterm>

For further configuration and/or installation of other hypervisors, check their specific guides: Xen, KVM and VMware.

5.2. Installing on openSUSE

When the front-end is installed, it is time to install the virtualization nodes. Depending on the chosen hypervisor, check their specific guides: Xen, KVM and VMware.

5.3. Installing on Debian/Ubuntu

When the front-end is installed, it is time to install the packages for the nodes if you are using KVM. To install a Debian/Ubuntu OpenNebula front-end with packages from our repository, execute the following as root:

<xterm> $ sudo dpkg -i opennebula-node-kvm $ sudo apt-get install -f </xterm>

For further configuration and/or installation of other hypervisors, check their specific guides: Xen, KVM and VMware.

:!: Due to the Debian packaging policy, there are some paths which are different in the Debian/Ubuntu packages with respect to OpenNebula's documentation. In particular:

  • /usr/share/one/examples/ ⇒ /usr/share/doc/opennebula/examples/
  • /usr/share/one/ ⇒ /usr/share/opennebula/

6. Manual Configuration of Unix Accounts

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(oneadmin) groups=1001(oneadmin) </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.

7. Manual Configuration of Secure Shell Access

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.

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. Also it is a good idea to reduced the connection timeout in case of network problems. This is configured into ~/.ssh/config, see man ssh_config for a complete reference.:

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

  StrictHostKeyChecking no

</xterm>

  • Check that the sshd daemon is running in the hosts. Also remove any Banner option from the sshd_config file in the hosts.
  • Finally, Copy the front-end /var/lib/one/.ssh directory to each one of the hosts in the same path.

To test your configuration just verify that oneadmin can log in the hosts without being prompt for a password.

8. Basic Networking Configuration

OpenNebula provides an easily adaptable and customizable network subsystem in order to better integrate with the specific network requirements of existing datacenters.

The network is needed by the OpenNebula front-end daemons to access the hosts to manage and monitor the hypervisors; and move image files. It is highly recommended to install a dedicated network for this purpose.

To offer network connectivity to the VMs across the different hosts, the default configuration connects the virtual machine network interface to a bridge in the physical host. To make an effective use of your VM deployments you'll probably need to make one or more physical networks accessible to them. Please check the Networking guide to find out the networking technologies supported by OpenNebula.

:!: You should create bridges with the same name in all the hosts. Depending on the network model, OpenNebula will dynamically create network bridges, please check the networking overview for more details.

For example, a typical host with two physical networks, one for public IP addresses (attached to eth0 NIC) and the other for private virtual LANs (NIC eth1) should have two bridges:

<xterm> $ brctl show bridge name bridge id STP enabled interfaces vbr0 8000.001e682f02ac no eth0 vbr1 8000.001e682f02ad no eth1 </xterm>

9. Basic Storage Configuration

OpenNebula uses Datastores to handle the VM disk Images. VM Images are registered, or created (empty volumes) in a Datastore. In general, each Datastore has to be accessible through the front-end using any suitable technology NAS, SAN or direct attached storage.

When a VM is deployed the Images are transferred from the Datastore to the hosts. Depending on the actual storage technology used it can mean a real transfer, a symbolic link or setting up an iSCSI target. Please check the the Storage guide for more details.

In the following sections we will show the basic installation and configuration using Filesystem Datastores (file-based disk images) and a Shared FS of any kind to transfer the datastore images. This way you can take full advantage of the hypervisor capabilities (i.e. live migration), and typically better VM deployment times.

There are two configuration steps needed to perform a basic set up:

  • First, you need to configure the system datastore to hold images for the running VMs, check the the System Datastore Guide, for more details.
  • Then you have to setup one ore more datastore for the disk images of the VMs, you can find more information on setting up Filesystem Datastores here.

:!: OpenNebula can work without a Shared FS. This will force the deployment to always clone the images and you will only be able to do cold migrations.