C12G has created an Image Contextualization Guide to give guidance on how to create and configure a VM Image to work in the OpenNebula environment. The new guide proposes techniques to create a VM Image from scratch and to prepare existing images to run with OpenNebula.

This article is part of the new Knowledge Base that is being extended by C12G Labs.

A couple of months have passed since the release of OpenNebula 2.2 (Cat’s Eye) and we have been quite active since then. The next release of OpenNebula is getting in shape fast and a significant amount of new features are already in the repository.

Let’s start reviewing the not-so-glamorous new features. One of the main themes for the next release is database refactoring. The new DB backend of OpenNebula features a schema free (document-oriented) implementation of the data model on top of a SQL DB. This will give us enough flexibility to easily extend the attributes and resources managed by OpenNebula at no performance cost. Also, the next release includes DB versioning and a tool to upgrade from previous versions of OpenNebula.

Another important area of work has been networking. We have evolved the network manager component to provide out-of-the-box integration with typical VLAN technologies. In particular, you’ll be able to choose from 802.1Q VLAN tagging, Open vSwitch and simple isolation based on ebtables filters. You’ll also be able to set up simple firewalling rules for each VM specifying black/white TCP/UDP port settings.

The next release will also feature important improvements in VM management. Virtual Machine templates can now be stored in OpenNebula so you can easily instantiate pre-defined configurations, and share them with other users. This new VM Template pool along with the existing Network and Image will give users and administrators a very flexible and simple way to define and instantiate virtual infrastructures.

We have also re-factored the Image Repository to adopt a pluggable architecture that can integrate any storage backend, with a filesystem-based repository provided in the next release. The Image Repository can be now further integrated with external catalogs. The next release will also showcase a preview of this hybrid cloud storage, that integrates Amazon S3 and OpenNebula, to download, contextualize and integrate S3 images in your local Image Repository.

Sunstone has also received some attention from the team, being extended to accommodate all the new features and some rough edges have been polished. We have also added support for plug-ins, enabling the easy customization of the control panel.  There is also a couple of new specific features for the interface: VNC access to VM instances through the web browser using noVNC; and graphical information about the health of your cloud.

And last but not least, the multi-tenancy support for OpenNebula has been considerably improved with the addition of groups and access control lists (ACLs). This will provide great flexibility to share resources among users and to define user roles. Grounded in this new functionality, you’ll be also able to experiment with the new Virtual Data Center (VDC) manager. Using a muti-tier architecture you’ll be able to aggregate multiple OpenNebula’s (zones) and define within them multiple, isolated VDCs.

Finally as you my have noticed from the title, there are so many new features (as well as changes in the database and internal API’s) that we have decided to upgrade the major versioning number of OpenNebula to 3. The changes in the public APIs are minimal and we expect that current applications will run without modifications on top of OpenNebula 3.0.

OpenNebula 3.0 also includes contributions from several members of our community, such as CERN, FermiLab, and Harvard University’s SEAS.

A beta version of OpenNebula 3.0 (codename Iris) will be ready for testing by the end of June and its stable release is scheduled on July 20th. As usual, OpenNebula releases are named after a Nebula. The Iris Nebula (NGC 7023, Caldwell 4) is a reflection nebula in the constellation of Cepheus.

We will appreciate your feedback on these new features. Thanks!

C12G Labs announced today new professional services offerings, which will enable customers and partners to take full advantage and maximize the value of OpenNebula industry-leading cloud management capabilities. C12G provides proven best practices and guidance from experts to design, deploy and operate the best cloud architecture for existing workload, processes and IT infrastructure environment. The new services, tailored to customer experience and requirements, include consulting, engineering, development and training.

C12G has created a Scalability Guide to give guidance on how to install and tune OpenNebula for optimal and scalable performance in your environment. The software comes with several modifiable parameters that can to be adapted to the specific needs of your infrastructure and workload.

This article is part of the new Knowledge Base that is being extended by C12G Labs.

C12G Labs announced today a major new release of OpenNebulaPro, the enterprise-class edition of the OpenNebula Toolkit. This is the third major release of the commercially supported, enterprise-ready distribution of the OpenNebula open-source toolkit, which is used by thousands of organizations worldwide.

OpenNebulaPro 2.2 offers a comprehensive solution for the management of virtualized data centers to enable private, public, hybrid (cloudbursting) and virtual private clouds. OpenNebulaPro 2.2 extends the fault-tolerance features of previous versions,  includes out-of-the-box integration with data-center’s monitoring systems, and brings the new Sunstone web application. C12G complements OpenNebulaPro 2.2 with additional tools to simplify the deployment and operation of Cloud instances and to help in the migration path from previous versions. As result of its certification process, it also provides a better integration with richer functionality on VMware and XenServer hypervisors.

OpenNebulaPro 2.2 includes state-of-the-art features developed to meet the requirements from High Performance Computing, Hosting and Telecom cloud environments. Telecom Operators can offer Virtual Private Cloud environments to extend the Private Clouds of their custormers over virtual private networks, so offering a more reliable and secure alternative to traditional Public Cloud providers. Supercomputing and leading research centers use OpenNebula to build clouds for hosting virtualized computational environments or for providing users with new “HPC as a service” resource provisioning models. Hosting providers are adopting OpenNebula to manage their infrastructure and to build new IaaS cloud offerings.

A recommendation for version 1.1 of the Open Cloud Computing Interface (OCCI) was recently released by the Open Grid Forum (OGF) (see OGF183 and OGF184). To add OCCI 1.1 support for OpenNebula, we created the Ecosystem project “OCCI for OpenNebula”. The goal of the project is to develop a complete, robust and interoperable implementation of OCCI 1.1 for OpenNebula.

Although the project is still in an early stage, today we released a first version that supports creating and deleting Virtual Networks, Images and Machines. Information on installation and configuration of the OCCI 1.1 extension can be found in the Wiki of the project.

Florian Feldhaus, Piotr Kasprzak – TU Dortmund

The OpenNebula Project is participating in several upcoming events in cloud computing:

Would be great to meet you at these venues.  If you want to connect, please send an email to contact@opennebula.org

C12G has created an introductory article to describe how to integrate public clouds with OpenNebula for Cloudbursting. The white paper describes the integration of public clouds with private cloud instances running OpenNebula. A general provisioning scenario that combines local and external cloud resources is first described. Afterwards the architecture of OpenNebula and the main components involved in a hybrid cloud setting are briefly presented. The document ends with some considerations and the minimum requirements to deploy a service in an hybrid cloud.

This article is part of the new Knowledge Base that is being extended by C12G Labs.

C12G/OpenNebula will participate in the panel about Cloud Computing Fostering Innovation of the workshop Towards a Cloud Computing Strategy for Europe: Matching Supply and Demand organized by the European Commission to help identify the main elements of a European Cloud Strategy. This panel will discuss the opportunities presented by the cloud, interoperability and standards issues, and the potential for innovation. Other panelists are senior-management representatives of European companies, organizations and networks, and the European Parliament. The workshop is part of the 1st Digital Agenda Assembly.

In this post, I will explain how to install OpenNebula on two servers in a fully redundant environment. This is the English translation of an article in Italian on my blog.

The idea is to have two Cloud Controllers in High Availability (HA) active/passive mode using Pacemaker/Heartbeat. These nodes will also provide storage by exporting a DRBD partition via ATA-Over-Ethernet; the VM disks will be created on logical LVM volumes in this partition. This solution, besides being totally redundant, will provide high-speed storage because we use snapshots to deploy the partitions of the VM, not using files on an NFS filesystem.

Nonetheless, we will still use NFS to export the /srv/cloud directory with OpenNebula data.

System Configuration

As a reference, this is the configuration of our own servers. Your servers do not have to be exactly the same; we will simply be using these two servers to explain certain aspects of the configuration.

First Server:

  • Linux Ubuntu 64-bit server 10.10
  • Cards eth0 and eth1 configured with IP bonding network (SAN)
  • ETH2 card with IP (LAN)
  • 1 TB internal HD partitioned as follows:
    • sda1: 40 GB mounted on /
    • sda2: 8 GB swap
    • sda3: 1 GB for metadata
    • sda5: 40 GB for /srv/cloud/one
    • sda6: 850 GB datastore

Secondary Server

  • Linux Ubuntu 64-bit server 10.10
  • Cards eth0 and eth1 configured with IP bonding network (SAN)
  • ETH2 card with IP (LAN)
  • 1 TB internal HD partitioned as follows:
    • sda1: 40 GB mounted on /
    • sda2: 8 GB swap
    • sda3: 1 GB for metadata
    • sda5: 40 GB for /srv/cloud/one
    • sda6: 850 GB datastore

Installing the base system

Install Ubuntu server 64-bit 10.10 on the two servers and enabling OpenSSH server during installation. In our case, the servers are each equipped with a double-disk 1TB SATA in hardware mirror, on which we will create a 40 GB partition (sda1) for the root filesystem, a 4 GB (sda2) for the swap, a third ( sda3) of 1 GB formetadata , a fourth (sda5) with 40 GB for the directory /srv/cloud/one replicated by DRBD, and a fifth (sda6) with the remaining space (approximately 850 GB) that will be used by DRBD for the export of VM filesystems.

In terms of network cards, we have a total of three network cards to each server: 2 (eth0, eth1) will be configured in bonding to manage data replication and communicate with the compute nodes in the cluster network (SAN) on the class and a third (eth2) is used to access from outside the cluster on the LAN with class.

Unless otherwise specified, these instructions are specific to the above two hosts, but should work on your own system with minor modifications.

Network Configuration

First we modify the hosts file:

/etc/hosts cloud-cc.lan.local cloud-cc cloud-cc01.lan.local cloud-cc02.lan.local cloud-01.san.local cloud-02.san.local cloud-03.san.local cloud-cc.san.local cloud-cc01.san.local cloud-cc01 cloud-cc02.san.local cloud-cc02

Next, we proceed to the configuration of the system. First configure the bonding interface, installing required packages:

apt-get install ethtool ifenslave

Then we load the module at startup with correct parameters creating file /etc/modprobe.d/bonding.conf

alias bond0
bonding options mode=0 miimon=100 downdelay=200 updelay=200

And configuring LAN:

auto bond0
iface bond0 inet static
bond_miimon  100
bond_mode balance-rr
address # on server 2
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1

auto eth2
iface eth2 inet static
address # on server 2

Configuring MySQL

I prefer to configure a MySQL circular replication rather than to manage the launch of the service through HeartBeat because MySQL is so fast in the opening; having been active on both servers, they save a few seconds during the switch in case of a fault.

First we install MySQL:

apt-get install mysql-server libmysqlclient16-dev libmysqlclient

and create the database for OpenNebula:

mysql -p
create database opennebula;
create user oneadmin identified by 'oneadmin';
grant all on opennebula.* to 'oneadmin'@'%';

Then we configure active/active replica on server 1:

/etc/mysql/conf.d/replica.cnf @ Server 1
bind-address			=
server-id                       = 10
auto_increment_increment        = 10
auto_increment_offset           = 1
master-host                     = server2.dominio.local
master-user                     = replicauser
master-password                 = replicapass
log_bin				= /var/log/mysql/mysql-bin.log
binlog_ignore_db		= mysql

And on server 2:

/etc/mysql/conf.d/replica.cnf @ server 2
bind-address			=
server-id                       = 20
auto_increment_increment        = 10
auto_increment_offset           = 2
master-host                     = server1.dominio.local
master-user                     = replicauser
master-password                 = replicapass
log_bin				= /var/log/mysql/mysql-bin.log
binlog_ignore_db		= mysql

Finally, on both servers, restart mysql and create replica user:

create user 'replicauser'@'%.san.local' identified by 'replicapass';
grant replication slave on *.* to 'replicauser'@'%.dominio.local';
start slave;
show slave status\G;

DRBD Configuration

Now is the turn of DRBD but configured in standard active/passive. First install the needed packages:

apt-get install drbd8 modprobe drbd-utils

So let’s edit the configuration file:

global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification

common {
protocol C;

handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;

startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb
wfc-timeout 120; ## 2 min
degr-wfc-timeout 120; ## 2 minutes.

disk {
# on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes
# no-disk-drain no-md-flushes max-bio-bvecs
on-io-error detach;

net {
# sndbuf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers
# max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret
# after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork
# allow-two-primaries;
# after-sb-0pri discard-zero-changes;
# after-sb-1pri discard-secondary;

timeout 60;
connect-int 10;
ping-int 10;
max-buffers 2048;
max-epoch-size 2048;

syncer {
# rate after al-extents use-rle cpu-mask verify-alg csums-alg
rate 500M;

And let’s create one-disk definition:

resource one-disk {
    on cloud-cc01 {
	device /dev/drbd1;
	disk /dev/sda5;
	meta-disk /dev/sda3[0];
    on cloud-cc02 {
	device /dev/drbd1;
	disk /dev/sda5;
	meta-disk /dev/sda3[0];

and data-disk:

resource data-disk {
    on cloud-cc01 {
	device /dev/drbd2;
	disk /dev/sda6;
	meta-disk /dev/sda3[1];
    on cloud-cc02 {
	device /dev/drbd2;
	disk /dev/sda6;
	meta-disk /dev/sda3[1];

Now, on both nodes, we create the metadata disk:

drbdadm create-md one-disk
drbdadm create-md data-disk
/etc/init.d/drbd reload

Finally, only on server 1, activate the disk:

drbdadm -- --overwrite-data-of-peer primary one-disk
drbdadm -- --overwrite-data-of-peer primary data-disk

Exporting the disks

As already mentioned, the two DRBD partitions will be visible through the network, although in different ways: one-disk will be exported through NFS, data-disk will be exported by ATA-over-Ethernet and will present its LVM partitions to the hypervisor.

Install the packages:

apt-get install vblade nfs-common nfs-kernel-server nfs-common portmap

We’ll disable automatic NFS and AoE startup because we handle it via HeartBeat:

update-rc.d nfs-kernel-server disable
update-rc.d vblade disable

Then we create the export for OpenNebula directory:


and we create necessary directory:

mkdir -p /srv/cloud/one

Finally we have to set idmapd daemon to correctly propagate user and permission on network.


Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = lan.local # Modify this


Nobody-User = nobody
Nobody-Group = nobody

Finally we have to configure default NFS settings:

NEED_SVCGSSD=no # no is default


NEED_GSSD=no # no is default

Fault Tolerant daemon configuration

There are two packages that can handle high available services on Linux: corosync and heartbeat. Personally I prefer heartbeat and provide instructions referring to this, but most configurations will be through the pacemaker, then you are perfectly free to opt for corosync.

First install the needed packages:

apt-get install heartbeat pacemaker

and configure heartbeat daemon:

autojoin none
bcast bond0
warntime 3
deadtime 6
initdead 60
keepalive 1
node cluster-cc01
node cluster-cc02
crm respawn

Only on first server, we create the authkeys file, and will copy it on the second server:

( echo -ne "auth 1\n1 sha1 "; \
  dd if=/dev/urandom bs=512 count=1 | openssl md5 ) \
  > /etc/ha.d/authkeys
chmod 0600 /etc/ha.d/authkeys
scp /etc/ha.d/authkeys cloud-cc02:/etc/ha.d/
ssh cloud-cc02 chmod 0600 /etc/ha.d/authkeys
/etc/init.d/heartbeat restart
ssh cloud-02 /etc/init.d/heartbeat restart

After a minute or two, heartbeat will be online:

crm_mon -1 | grep Online
Online: [ cloud-cc0 cloud-cc02 ]

Now we’ll configure cluster services via pacemaker.
Setting default options:

crm configure
property no-quorum-policy=ignore
property stonith-enabled=false
property default-resource-stickiness=1000

The two shared IP and

crm configure
primitive lan_ip IPaddr params ip= cidr_netmask="" nic="eth2" op monitor interval="40s" timeout="20s"
primitive san_ip IPaddr params ip= cidr_netmask="" nic="bond0" op monitor interval="40s" timeout="20s"

The NFS export:

crm configure
primitive drbd_one ocf:linbit:drbd params drbd_resource="one-disk" op monitor interval="40s" timeout="20s"
ms ms_drbd_one drbd_one meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

The one-disk mount:

crm configure
primitive fs_one ocf:heartbeat:Filesystem params device="/dev/drbd/by-res/one-disk" directory="/srv/cloud/one" fstype="ext4"

The AoE export:

crm configure
primitive drbd_data ocf:linbit:drbd params drbd_resource="data-disk"  op monitor interval="40s" timeout="20s"
ms ms_drbd_data drbd_data meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

The data-disk mount:

crm configure
primitive aoe_data ocf:heartbeat:AoEtarget params device="/dev/drbd/by-res/data-disk" nic="bond0" shelf="0" slot=="0" op monitor interval="40s" timeout="20s"

Now we have to configure the correct order to startup services:

crm configure
group ha_group san_ip lan_ip fs_one nfs_one aoe_data
colocation ha_col inf: ha_group ms_drbd_one:Master ms_drbd_data:Master
order ha_after_drbd inf: ms_drbd_one:promote ms_drbd_data:promote ha_group:start

We will modify this configuration later to add OpenNebula and lighttpd startup.

LVM Configuration

LVM2 will allow us to create partitions for virtual machines and deploy it via snapshot basis.

Install the package on both machines.

apt-get install lvm2

We have to modify the filter configuration to allow lvm scan only to DRBD disk.

filter = [ "a|drbd.*|", "r|.*|" ]
write_cache_state = 0

ATTENTION: Ubuntu uses a Ramdisk to bootup the system, so we have to modify also lvm.conf file inside ramdisk.

Now we remove the cache:

rm /etc/lvm/cache/.cache

Only on server 1 we have to create physical LVM volume and Volume Group:

pvcreate /dev/drbd/by-res/data-disk
vgcreate one-data /dev/drbd2

Install and configure OpenNebula

We are almost done. Now we download and install OpenNebula 2.2 via source:

First we have to install prerequisites:

apt-get install libsqlite3-dev libxmlrpc-c3-dev scons g++ ruby libopenssl-ruby libssl-dev ruby-dev make rake rubygems libxml-parser-ruby1.8 libxslt1-dev libxml2-dev genisoimage  libsqlite3-ruby libsqlite3-ruby1.8 rails thin
gem install nokogiri
gem install json
gem install sinatra
gem install rack
gem install thin
cd /usr/bin
ln -s rackup1.8 rackup

Then we have to create OpenNebula user and group:

groupadd cloud
useradd -d /srv/cloud/one  -s /bin/bash -g cloud -m oneadmin
chown -R oneadmin:cloud /srv/cloud/
chmod 775 /srv
id oneadmin # we have to use this id also on cluster node for oneadmin/cloud

Now we go in unpriviledged mode to create ssh certificate for cluster communications:

su - oneadmin
ssh-keygen # use default
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chown 640 ~/.ssh/authorized_keys
mkdir  ~/.one

We create a .profile file with default variables:

export ONE_AUTH='/srv/cloud/one/.one/one_auth'
export ONE_LOCATION='/srv/cloud/one'
export ONE_XMLRPC='http://localhost:2633/RPC2'
export PATH=$PATH':/srv/cloud/one/bin'

Now we have to create one_auth file to setup a default user inside OpenNebula (for example of api or sunstone):


And load default variables before compile:

source .profile

Now download and install OpenNebula:

wget http://dev.opennebula.org/attachments/download/339/opennebula-2.2.tar.gz
tar zxvf opennebula-2.2.tar.gz
cd opennebula-2.2
scons -j2 mysql=yes
./install.sh -d /srv/cloud/one

About configuration: this is my oned.conf file, I use Xen HyperVisor, but you can use also KVM.






DB = [ backend = "mysql",
       server  = "localhost",
       port    = 0,
       user    = "oneadmin",
       passwd  = "oneadmin",
       db_name = "opennebula" ]




MAC_PREFIX   = "02:ab"

IMAGE_REPOSITORY_PATH = /srv/cloud/one/var/images

IM_MAD = [
    name       = "im_xen",
    executable = "one_im_ssh",
    arguments  = "xen" ]

VM_MAD = [
    name       = "vmm_xen",
    executable = "one_vmm_ssh",
    arguments  = "xen",
    default    = "vmm_ssh/vmm_ssh_xen.conf",
    type       = "xen" ]

TM_MAD = [
    name       = "tm_lvm",
    executable = "one_tm",
    arguments  = "tm_lvm/tm_lvm.conf" ]

HM_MAD = [
    executable = "one_hm" ]

    name      = "image",
    on        = "DONE",
    command   = "image.rb",
    arguments = "$VMID" ]

    name      = "error",
    on        = "ERROR",
    command   = "host_error.rb",
    arguments = "$HID -r n",
    remote    = "no" ]

   name      = "on_failure_resubmit",
   on        = "FAILED",
   command   = "/usr/bin/env onevm resubmit",
   arguments = "$VMID" ]

The only important thing is to modify /srv/cloud/one/etc/tm_lvm/tm_lvm.rc setting default VG:


Now copy the init.d script from source to /etc/init.d but not set it to startup ad boot.

I have modified the default script to startup also sunstone:

#! /bin/sh
# Provides:          opennebula
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: OpenNebula init script
# Description:       OpenNebula cloud initialisation script

# Author: Soren Hansen - modified my Alberto Zuin

DESC="OpenNebula cloud"

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

# Function that starts the daemon/service
mkdir -p /var/run/one /var/lock/one
chown oneadmin /var/run/one /var/lock/one
su - oneadmin -s /bin/sh -c "$DAEMON start"
su - oneadmin -s /bin/sh -c "$SUNSTONE start"

# Function that stops the daemon/service
su - oneadmin -s /bin/sh -c "$SUNSTONE stop"
su - oneadmin -s /bin/sh -c "$DAEMON stop"

case "$1" in
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
# If the "reload" option is implemented then remove the
# 'force-reload' alias
log_daemon_msg "Restarting $DESC" "$NAME"
case "$?" in
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
# Failed to stop
log_end_msg 1
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 3


and set it with execute permissions:

chmod 755 /etc/init.d/one

Configuring the HTTPS proxy for Sunstone

Sunstone is the web interface for Cloud administration, if you do not want to use the command line… works on port 4567 and is not encrypted, so we’ll use lighttpd for proxy requests to HTTPS encrypted connection.

First install the daemon:

apt-get install ssl-cert lighttpd

Then generate certificates:

/usr/sbin/make-ssl-cert generate-default-snakeoil
cat /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem > /etc/lighttpd/server.pem

and create symlinks to enable ssl and proxy modules:

ln -s /etc/lighttpd/conf-available/10-ssl.conf /etc/lighttpd/conf-enabled/
ln -s /etc/lighttpd/conf-available/10-proxy.conf /etc/lighttpd/conf-enabled/

And modify lighttp setup to enable proxy to sunstone:

proxy.server               = ( "" =>
                                ("" =>
                                 "host" => "",
                                 "port" => 4567

Starting LightHTTP and OpenNebula with heartbeat

Now add the startup script automatically to heartbeat. First all stop heartbeat on both servers:

crm node
standby cloud-cc01
standby cloud-cc02

Then we can change the configuration:

crm configure
primitive OpenNebula lsb:one
primitive lighttpd lsb:lighttpd
delete ha_group
group ha_group san_ip lan_ip fs_one nfs_one aoe_data OpenNebula lighttpd
colocation ha_col inf: ha_group ms_drbd_one:Master ms_drbd_data:Master
order ha_after_drbd inf: ms_drbd_one:promote ms_drbd_data:promote ha_group:start

And startup the cluster again:

crm node
online cloud-cc01
online cloud-cc02

That’s all folks!
Alberto Zuin – http://www.anzs.it