OpenNebula - Flexible Enterprise Cloud Made Simple documentation:archives:rel3.4

documentation:archives:rel3.4:accounting

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The accounting toolset visualizes and reports resource usage data, and allows their integration with chargeback and billing platforms. The toolset generates accounting reports using the information from the accounting OpenNebula Database. These accounting tools address the accounting of the virtual resources, it includes resource consumption of the virtual machines as reported from the hypervisor.

documentation:archives:rel3.4:acctd_conf

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula Watch is an utility that provides statistics and accounting information for cloud resources. These values can be used by: * Users, to track information of their resources. * Cloud administrators, to get a global vision of the Cloud and the resource utilization in order to identify potential problems and react immediately.

documentation:archives:rel3.4:api

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This reference documentation describes the xml-rpc methods exposed by OpenNebula. Each description consists of the method name and the input and output values. All xml-rpc responses share a common structure. Type Data Type Description OUT Boolean

documentation:archives:rel3.4:auth_overview

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula includes a complete user & group management system. Users in an OpenNebula installation are classified in four types: * Administrators, an admin user belongs to the oneadmin group and can perform any operation * Regular users, that may access most OpenNebula functionality.

documentation:archives:rel3.4:build_deps

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page lists the build dependencies for OpenNebula. If you want to install it from your package manager, visit the software menu to find out if OpenNebula is included in your official distribution package repositories. * g++ compiler (>= 4.0) * xmlrpc-c

documentation:archives:rel3.4:catalog

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

:!: Development version of OpenNebula 3.0. The material on this page needs to be reviewed for completeness and accuracy. Overview The OpenNebula Catalog is a new tool that will allow us to import disk images from external storage providers. In addition, this tool will adapt the image so it will benefit from the OpenNebula contextualization. In this first version we have included an Amazon S3 driver, therefore you will be able to import your EC2 amis into OpenNebula.

documentation:archives:rel3.4:cg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide aim is to give pointers to configure all the components available in OpenNebula. It is assumed that the infrastructure is prepared and OpenNebula is correctly installed. Therefore, the following sections cover each specific component of OpenNebula that can be tailored and/or configured to better adjust the OpenNebula installation to the particular needs of your infrastructure and the potential cloud users.

documentation:archives:rel3.4:chmod

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Most OpenNebula resources have associated permissions for the owner, the users in her group, and others. For each one of these groups, there are three rights that can be set: USE, MANAGE and ADMIN. These permissions are very similar to those of UNIX file system.

documentation:archives:rel3.4:cli

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula provides a set commands to interact with the system: * oneacl: manages OpenNebula ACLs * onecluster: manages OpenNebula clusters * onedatastore: manages OpenNebula datastores * onegroup: manages groups of users * onehost: to add, delete and monitor hosts * onecluster: manages Clusters

documentation:archives:rel3.4:cloud_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula ships with three servers: Sunstone, EC2 and OCCI. When a user interacts with one of them, the server authenticates the request and then forwards the requested operation to the OpenNebula daemon. The forwarded requests between the servers and the core daemon include the original user name, and are signed with the credentials of an special

documentation:archives:rel3.4:cluster_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

A Cluster is a group of Hosts. Clusters can have associated Datastores and Virtual Networks, this is how the administrator sets which Hosts have the underlying requirements for each Datastore and Virtual Network configured. Cluster Management Clusters are managed with the ''onecluster'' command. To create new Clusters, use

documentation:archives:rel3.4:compatibility

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide is aimed at OpenNebula 3.2 users and administrators who want to upgrade to the latest 3.4 version. The following sections summarize the new features and usage changes that should be taken into account, or prone to cause confusion. You can check the upgrade process in the following

documentation:archives:rel3.4:compile

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page will show you how to compile and install OpenNebula from the sources. If you want to install it from your package manager, visit the software menu to find out if OpenNebula is included in your official distribution package repositories. :!: Do not forget to check the

documentation:archives:rel3.4:cong

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

There are two contextualization mechanisms available in OpenNebula: the automatic IP assignment, and a more generic way to give any file and configuration parameters. You can use any of them individually, or both. Using Virtual Network Leases within a Virtual Machine

documentation:archives:rel3.4:dbschema

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page presents a simplified view of the database schema used by the acct daemon. It includes the tables relevant for third party accounting or statistics software developers. Virtual Machines * TABLE: vms * PRIMARY KEY: id Name SQL Type

documentation:archives:rel3.4:devel-vmm

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The component that deals with the hypervisor to create, manage and get information about virtual machine objects is called Virtual Machine Manager (VMM for short). This component has two parts. The first one resides in the core and holds most of the general functionality common to all the drivers (and some specific), the second is the driver that is the one able to translate basic VMM actions to the hypervisor.

documentation:archives:rel3.4:ebtables

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide describes how to enable Network isolation provided through ebtables rules applied on the bridges. This method will only permit isolation with a mask of 255.255.255.0. Requirements This hook requires ebtables to be available in all the OpenNebula Hosts.

documentation:archives:rel3.4:ec2g

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

You should take into account the following technical considerations when using the EC2 cloud with OpenNebula: * There is no direct access to the dom0, so it cannot be monitored (we don't know where the VM is running on the EC2 cloud). * The usual OpenNebula functionality for snapshotting, restoring, or migration is not available with EC2.

documentation:archives:rel3.4:ec2qcg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The OpenNebula EC2 Query is a web service that enables you to launch and manage virtual machines in your OpenNebula installation through the Amazon EC2 Query Interface. In this way, you can use any EC2 Query tool or utility to access your Private Cloud. The EC2 Query web service is implemented upon the

documentation:archives:rel3.4:ec2qcs

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

COMMON_OPTIONS VALUE --help, -h Show help --access-key , -K The name of the user --secret-key , -S The password of the user --url , -U

documentation:archives:rel3.4:ec2qec

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

In order to interact with the EC2 Service that OpenNebula implements you can use the client included in the OpenNebula distribution, but also you can choose one of the well known tools that are supposed to interact with cloud servers through the EC2 Query

documentation:archives:rel3.4:ec2qug

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The EC2 Query API offers the functionality exposed by Amazon EC2: upload images, register them, run, monitor and terminate instances, etc. In short, Query requests are HTTP or HTTPS requests that use the HTTP verb GET or POST and a Query parameter. OpenNebula implements a subset of the EC2 Query interface, enabling the creation of public clouds managed by OpenNebula. In this first release of the

documentation:archives:rel3.4:evmwareg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The VMware Drivers enable the management of an OpenNebula cloud based on VMware ESX and/or VMware Server hypervisors. It uses libvirt to invoke the Virtual Infrastructure SOAP API exposed by the VMware hypervisors, and it entails a much better integration and performance than the java based drivers traditionally found in the OpenNebula distribution.

documentation:archives:rel3.4:external_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula comes by default with an internal user/password authentication and an ACL authorization system, see the Users & Groups Subsystem guide for more information. You can enable the external Authentication and Authorization drivers to strengthen the security of your cloud.

documentation:archives:rel3.4:features

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This section describes the key features and functionality of the last version of OpenNebula (v3.4) for the comprehensive management of virtualized data centers to enable private, public and hybrid (cloudbursting) clouds. It also includes links to the different parts of the documentation and the web site that provide extended information about each feature.

documentation:archives:rel3.4:firewall

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This driver installs iptables rules in the physical host executing the VM. This driver can be used to filter (and enforce) TCP and UDP ports, and to define a policy for ICMP connections, without any additional modification to the guest VMs. Requirements

documentation:archives:rel3.4:fs_ds

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The Filesystem datastore lets you store VM images in a file form. The datastore is format agnostic, so you can store any file-type depending on the target hypervisor. The use of file-based disk images presents several benefits over deviced backed disks (e.g. easily backup images, or use of shared FS) although it may less performing in some cases.

documentation:archives:rel3.4:ftguide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide's objective is to provide information in order to prepare for failures and/or recover from them. This failures are categorized depending on whether they come from the physical infrastructure (Host failures), from the virtualized infrastructure (VM crashes) or from the virtual infrastructure manager (OpenNebula crash).

documentation:archives:rel3.4:ganglia

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

If you already have ganglia deployed in your cluster you can use the ganglia drivers provided by OpenNebula to get information about hosts and virtual machines from it. These drivers should make the monitoring more performant in a big installation as they don't use ssh connections to the nodes to get the information. On the other side they require more work on the system administrator as ganglia should be properly configured and cron jobs must be installed on the nodes to provide virtual machine…

documentation:archives:rel3.4:glossary

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula components: * Front-end: Machine running the OpenNebula services. * Host: Physical machine running a supported hypervisor. See the Host subsystem. * Cluster: Pool of hosts that share datastores and virtual networks. Clusters are used for load balancing, high availability, and high performance computing.

documentation:archives:rel3.4:hm-vlan

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide describes how to enable Network isolation provided through host-managed VLANs. This driver will create a bridge for each OpenNebula Virtual Network and attach an VLAN tagged network interface to the bridge. This mechanism is compliant with

documentation:archives:rel3.4:hooks

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Hook Manager present in OpenNebula enables the triggering of custom scripts tied to a change in state in a particular resource, being that a Host or a Virtual Machine. This opens a wide area of automation for system administrators to tailor their cloud infrastructures.

documentation:archives:rel3.4:hostsubsystem

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

What is a Cluster Clusters are pools of hosts that share datastores and virtual networks. Clusters are used for load balancing, high availability, and high performance computing. What is a Host A Host is a server that has the ability to run Virtual Machines and that is connected to OpenNebula's Frontend server. OpenNebula can work with Hosts with a heterogeneous configuration, i.e. you can connect Hosts to the same OpenNebula with different hypervisors or Linux distributions as long as thes…

documentation:archives:rel3.4:host_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

In order to use your existing physical nodes, you have to add them to the system as OpenNebula hosts. You need the following information: * Hostname of the host or IP * Information Driver to be used to monitor the host, e.g. im_kvm. These should match the Virtualization Drivers installed and more info about them can be found at the

documentation:archives:rel3.4:ignc

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page will show you how to install OpenNebula from the binary packages. Please read the Planning the Installation guide before you proceed. 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.

documentation:archives:rel3.4:image_repo

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The image repository is the on in charge to store and manage registered images. You can get more information on its usage from a user perspective in the Managing Virtual Machine Images guide. The way the image repository accomplishes these tasks is through a driver that knows how to perform these actions:

documentation:archives:rel3.4:img

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Information Manager (IM) is in charge of monitoring the hosts. It comes with various sensors, each one responsible of a different aspects of the computer to be monitored (CPU, memory, hostname...). Also, there are sensors prepared to gather information from different hypervisors.

documentation:archives:rel3.4:img_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Storage system allows OpenNebula administrators and users to set up images, which can be operative systems or data, to be used in Virtual Machines easily. These images can be used by several Virtual Machines simultaneously, and also shared with other users.

documentation:archives:rel3.4:img_mad

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Image Manager Driver is quite similar to the Transfer Manager Driver. This Manager Driver is responsible for the file management needed to create new Images. Image Manager Driver Configuration Only one Image Manager Driver can be configured in oned.conf. The default configuration is as follows:

documentation:archives:rel3.4:img_template

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page describes how to define a new image template. An image template follows the same syntax as the VM template. If you want to learn more about the image repository, you can do so here. :!: There are some template attributes that can compromise the security of the system or the security of other VMs, and can be used

documentation:archives:rel3.4:intro

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula is the open-source industry standard for data center virtualization, offering the most feature-rich, flexible solution for the comprehensive, complete management of virtualized data centers to enable on-premise IaaS clouds in existing infrastructures. OpenNebula interoperability makes cloud an evolution by leveraging existing IT assets, protecting your investments, and avoiding vendor lock-in.

documentation:archives:rel3.4:introapis

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula has been designed to be easily adapted to any infrastructure and easily extended with new components. The result is a modular system that can implement a variety of Cloud architectures and can interface with multiple datacenter services. In this document we will review the main interfaces of OpenNebula (see figure 1 for an overview), their use and give pointers to additional documentation for each one. We have classified the interfaces in two categories: end-user cloud and system in…

documentation:archives:rel3.4:introc

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

What is a Public Cloud? A Public Cloud is an extension of a Private Cloud to expose RESTful Cloud interfaces. Cloud interfaces can be added to your Private or Hybrid Cloud if you want to provide partners or external users with access to your infrastructure, or to sell your overcapacity. Obviously, a local cloud solution is the natural back-end for any public cloud.

documentation:archives:rel3.4:introh

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

What is a Hybrid Cloud? A Hybrid Cloud is an extension of a Private Cloud to combine local resources with resources from remote Cloud providers. The remote provider could be a commercial Cloud service, such as Amazon EC2, or a partner infrastructure running a different OpenNebula instance. Such support for cloudbursting enables highly scalable hosting environments.

documentation:archives:rel3.4:intropr

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The aim of a Private Cloud is not to expose to the world a cloud interface to sell capacity over the Internet, but to provide local cloud users and administrators with a flexible and agile private infrastructure to run virtualized service workloads within the administrative domain

documentation:archives:rel3.4:iscsi_ds

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The iSCSI datastore driver provides OpenNebula with the possibility of using block-devices for VM images instead of the default file form. The use of the iSCSI datastores presents several benefits, especially regarding performance. It is developed to work with tgtd, the Linux SCSI target framework. However this driver is written in a way it can be easily hacked into working with specific SAN systems or other iSCSI target softwares.

documentation:archives:rel3.4:java

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page contains the OpenNebula Cloud API Specification for Java. It has been designed as a wrapper for the XML-RPC methods, with some basic helpers. This means that you should be familiar with the XML-RPC API and the XML formats returned by the OpenNebula core. As stated in the

documentation:archives:rel3.4:known_issues

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The following bugs or issues have been identified in the current 3.4 version, and will be solved in future releases. OpenNebula 3.4 * Sunstone monitoring graphs are not correctly shown for oneadmin or users in oneadmin group * To fix it, apply these patches

documentation:archives:rel3.4:kvmg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

KVM (Kernel-based Virtual Machine) is a complete virtualization technique for Linux. It offers full virtualization, where each Virtual Machine interacts with its own virtualized hardware. This guide describes the use of the KVM virtualizer with OpenNebula, please refer to KVM specific documentation for further information on the setup of the KVM hypervisor itself.

documentation:archives:rel3.4:ldap

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The LDAP Authentication addon permits users to have the same credentials as in LDAP, so effectively centralizing authentication. Enabling it will let any correctly authenticated LDAP user to use OpenNebula. Prerequisites This Addon uses the 'net/ldap' ruby library provided by the 'net-ldap' gem.

documentation:archives:rel3.4:log_debug

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula keeps separate log files for each active component, all of them stored in /var/log/one. To help users and administrators find and solve problems, they can also access some of the error messages from the CLI or the Sunstone GUI. Log Files There are different log files corresponding to different OpenNebula components:

documentation:archives:rel3.4:lvm

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Although OpenNebula 3.4 was released initially without LVM support, the LVM drivers for the next release: OpenNebula 3.6 are already in place and can be adapted to work with OpenNebula 3.4. Installing and configuring Download the tar from here And the run: $ tar xzf opennebula-3.4-lvm.tar.gz $ cp -r opennebula-3.4-lvm/datastore_mad/lvm /var/lib/one/remotes/datastore/ $ cp -r opennebula-3.4-lvm/tm_mad/lvm /var/lib/one/remotes/tm/

documentation:archives:rel3.4:manage_acl

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The ACL authorization system enables fine-tuning of the allowed operations for any user, or group of users. Each operation generates an authorization request that is checked against the registered set of ACL rules. The core then can grant permission, or reject the request.

documentation:archives:rel3.4:manage_users

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula supports user accounts and groups. This guide shows how to manage both. To manage user rights, visit the Managing ACL Rules guide. Users A user in OpenNebula is defined by a username and password. You don't need to create a new Unix account in the front-end for each OpenNebula user, they are completely different concepts. OpenNebula users are authenticated using a session string included in every

documentation:archives:rel3.4:mysql

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The MySQL backend was introduced in OpenNebula 2.0 as an alternative to the Sqlite backend available in previous releases. Either of them can be used seamlessly to the upper layers and ecosystem tools. These high level components do not need to be modified or configured.

documentation:archives:rel3.4:nm

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview Before diving into Network configuration in OpenNebula make sure that you've followed the steps described in the Networking section of the Planning the Installation guide. When a new Virtual Machine is launched, OpenNebula will connect its network interfaces (defined in the NIC section of the template) to the bridge or physical device specified in the

documentation:archives:rel3.4:occicg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The OpenNebula OCCI (Open Cloud Computing Interface) server is a web service that enables you to launch and manage virtual machines in your OpenNebula installation using an implementation of the OGF OCCI API specification based on the draft 0.8. This implementation also includes some extensions, requested by the community, to support OpenNebula specific functionality. The OpenNebula OCCI service is implemented upon the

documentation:archives:rel3.4:occidd

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The OpenNebula OCCI API is a RESTful service to create, control and monitor cloud resources using an implementation of the OGF OCCI API specification based on the draft 0.8. This implementation also includes some extensions, requested by the community, to support OpenNebula specific functionality. There are two types of resources that resemble the basic entities managed by the OpenNebula system, namely:

documentation:archives:rel3.4:occiug

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The OpenNebula OCCI API is a RESTful service to create, control and monitor cloud resources using an implementation of the OGF OCCI API specification based on the draft 0.8. This implementation also includes some extensions, requested by the community, to support OpenNebula specific functionality. Interactions with the resources are done through HTTP verbs (

documentation:archives:rel3.4:onecast

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

:!: Development version of OpenNebula 3.0. The material on this page needs to be reviewed for completeness and accuracy. :!: To use this functionality you need to install the onecast Addon onecast is a tool that can rewrite parts of a VM description substituting the variables it contains by some values that the user provides. It also gets values from the environment if the values are not explicitly provided by the user and can also have a default value so they will be translated to somethin…

documentation:archives:rel3.4:oned_conf

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The OpenNebula daemon oned manages the cluster nodes, virtual networks, virtual machines, users, groups and image repository. The configuration file for the daemon is called oned.conf and it is placed inside the /etc/one directory. In this reference document we describe all the format and options that can be specified in

documentation:archives:rel3.4:openvswitch

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide describes how to enable Network isolation provided through Open vSwitch. Each Virtual Network interface will receive a VLAN tag enabling network isolation. Other traffic attributes that may be configured through Open vSwitch are not modified. The VLAN id will be the same for every interface in a given network, calculated by adding a constant to the network id. It may also be forced by specifying an VLAN_ID parameter in the

documentation:archives:rel3.4:ozones

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The OpenNebula Zones (oZones) component allows for the centralized management of multiple instances of OpenNebula (zones), managing in turn potentially different administrative domains. The module is run by the oZones administrator, with capacity to grant access to the different zones to particular users.

documentation:archives:rel3.4:ozonescfg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide intends to give a walk through the steps needed to correctly configure the oZones Server to start managing Zones and VDCs. Also, it provides steps to configure a reverse proxy based on the Apache web server to hide the VDC details from end users.

documentation:archives:rel3.4:plan

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide provides a high-level overview of an OpenNebula installation, so you can easily architect your deployment and understand the technologies involved in the management of virtualized resources and their relationship. OpenNebula assumes that your physical infrastructure adopts a classical cluster-like architecture with a front-end, and a set of hosts where Virtual Machines (VM) will be executed. There is at least one physical network joining all the hosts with the front-end.

documentation:archives:rel3.4:quota_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide will show you how to enable and use the Quota authorization. When quota module is enabled it checks for user resource consumption before letting a Virtual Machine or Image to be created in the OpenNebula system. Requirements You don't need to install any additional software.

documentation:archives:rel3.4:ruby

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page contains the OpenNebula Cloud API Specification for Ruby. It has been designed as a wrapper for the XML-RPC methods, with some basic helpers. This means that you should be familiar with the XML-RPC API and the XML formats returned by the OpenNebula core. As stated in the

documentation:archives:rel3.4:schg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Scheduler module is in charge of the assignment between pending Virtual Machines and known Hosts. OpenNebula's architecture defines this module as a separate process that can be started independently of oned. The OpenNebula scheduling framework is designed in a generic way, so it is highly modifiable and can be easily replaced by third-party developments.

documentation:archives:rel3.4:sd

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Storage subsystem is highly modular. These drivers are separated into two logical sets: * DS: Datastore drivers. They serve the purpose of managing images: register, delete, and create empty datablocks. * TM: Transfer Manager drivers. They manage images associated to instantiated VMs.

documentation:archives:rel3.4:sd_dump

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

0 0 0 oneadmin oneadmin TTY 1 1 0 0 0 0 0 0 0 0 0

documentation:archives:rel3.4:selfservice

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula Self-Service is a simplified GUI aimed to end-users of the OpenNebula cloud. Its aim is to offer a simplified access to shared infrastructure for non-IT end users. Self-Service works on top of OpenNebula's OCCI server and it allows users to easily create, deploy and manage compute, storage (including the upload of images) and network resources.

documentation:archives:rel3.4:selfservicebranding

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula Self-Service can be easily customized to include the informations you consider more relevant to its users. Customizable options Customizable options are: * Login Self-Service logo and top-left logo in the main views. * Title, texts and images in the dashboard boxes.

documentation:archives:rel3.4:sm

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

What is a Datastore? A Datastore is any storage medium used to store disk images for VMs, previous versions of OpenNebula refer to this concept as Image Repository. Typically, a datastore will be backed by SAN/NAS servers. An OpenNebula installation can have multiple datastores of several types to store disk images. OpenNebula also uses a special datastore, the

documentation:archives:rel3.4:ssh_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide will show you how to enable and use the SSH authentication for the OpenNebula CLI. Using this authentication method, users login to OpenNebula with a token encrypted with their private ssh keys. Requirements You don't need to install any additional software.

documentation:archives:rel3.4:statistics_api

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page contains the OpenNebula Statistics API implementation for Ruby. It has been designed for retrieving utilization information of the Cloud. This version of the API supports Virtual Machine and Host statistics. Retrieving Resource Information

documentation:archives:rel3.4:sunstone

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

OpenNebula Sunstone is the OpenNebula Cloud Operations Center, a Graphical User Interface (GUI) intended for regular users and administrators that simplifies the typical management operations in private and hybrid cloud infrastructures. OpenNebula Sunstone allows to easily manage all OpenNebula resources and perform typical operations on them.

documentation:archives:rel3.4:sunstone_dummy_plugin

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Sunstone Dummy Plugin is a simple plugin to illustrate the pluging creation process explained in Sunstone Plugin Guide and to test some of the Sunstone features which are not used by the standard plugins. In order to use it just save the following code in the public/js/plugins/

documentation:archives:rel3.4:sunstone_plugin_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Sunstone client-side has a plugin-oriented structure that allows users to select which features are active and to develop their own extensions and easily include them in the web interface. Plugins can use the Sunstone interface to run and modify common OpenNebula actions, show custom information panels and offer extended capabilities for Sunstone.

documentation:archives:rel3.4:sunstone_plugin_reference

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This document is intended to provide a detailed description for sunstone.js configuration objects and methods regarding the creation and use of plugins. For information on how to write a plugin for Sunstone please read the Sunstone Plugin Guide :!: Sunstone plugins are part of the client-side of Sunstone. Therefore, they are written in Javascript and allow customization and extension of the user interface, which is fully on the client-side.

documentation:archives:rel3.4:system_ds

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The system datastore holds images for running VMs. There is only one system datastore in an OpenNebula installation and it cannot be used to manually register images. OpenNebula automatically copies, moves and deletes images from it as the VMs need them.

documentation:archives:rel3.4:template

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

A template file consists of a set of attributes that defines a Virtual Machine. Using the command onetemplate create, a template can be registered in OpenNebula to be later instantiated. For compatibility with previous versions, you can also create a new Virtual Machine directly from a template file, using the

documentation:archives:rel3.4:template_simple

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This is the simplified version of the complete definition file reference. In this guide, only the basic attributes and functionality are described. A template file consists of a set of attributes that defines a Virtual Machine. Using the command onetemplate create, a template can be registered in OpenNebula to be later instantiated.

documentation:archives:rel3.4:upgrade

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide describes the installation procedure for systems that are already running a 2.x or 3.x OpenNebula. The upgrade will preserve all current users, hosts, resources and configurations; for both Sqlite and MySQL backends. Read the Compatibility Guide and Relase Notes to know what is new in OpenNebula 3.4 .

documentation:archives:rel3.4:vdcmngt

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Virtual Data Centers (VDCs) are fully-isolated virtual infrastructure environments where a group of users, under the control of the VDC administrator, can create and manage compute, storage and networking capacity. The VDC administrator can create new users inside the VDC. Both VDC admins and users access the zone through a reverse proxy, so they don't need to know the endpoint of the zone, but rather the address of the oZones module and the VDC where they belong to.

documentation:archives:rel3.4:vgg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

A host is connected to one or more networks that are available to the virtual machines through the corresponding bridges. OpenNebula allows the creation of Virtual Networks by mapping them on top of the physical ones Overview In this guide you'll learn how to define and use virtual networks. For the sake of simplicity the following examples assume that the hosts are attached to two

documentation:archives:rel3.4:vmg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The purpose of this section is to demonstrate how to quickly deploy a VM with OpenNebula in a few easy steps. We will assume that you have properly configured OpenNebula and that you have at least one worker node running KVM (this guide does not work with Xen for the moment).

documentation:archives:rel3.4:vmmg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The Virtualization Subsystem is the component in charge of talking with the hypervisor installed in the hosts and taking the actions needed for each step in the VM lifecycle. Configuration options and specific information for each hypervisor can be found in these guides:

documentation:archives:rel3.4:vmwarenet

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide describes how to use the VMware network drivers in OpenNebula, which use native VMware networks. It's designed to be used as the network driver for VMware hypervisors. This driver optionally provides network isolation through VLAN tagging. The VLAN id will be the same for every interface in a given network, calculated by adding a constant to the network id. It may also be forced by specifying an VLAN_ID parameter in the

documentation:archives:rel3.4:vmware_ds

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

Overview The VMware datastore lets you store VM images to be used with the VMware hypervisor family. The VMware datastore is an specialized version of the Filesystem datastore that deals with the vmdk format. Considerations are also need to be taken into account regarding the system datastore, since compatibility must be ensured between the system datastore and all the registered datastores.

documentation:archives:rel3.4:vm_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

In OpenNebula the Virtual Machines are defined with Template definition files. This guide explains how to describe the wanted-to-be-ran Virtual Machine, and how users typically interact with the system. The Template Repository system allows OpenNebula administrators and users to register Virtual Machine definitions in the system, to be instantiated later as Virtual Machine instances. These Templates can be instantiated several times, and also shared with other users.

documentation:archives:rel3.4:vm_guide_2

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide follows the Creating Virtual Machines guide. Once a Template is instantiated to a Virtual Machine, there are a number of operations that can be performed using the onevm command. Sunstone You can manage your virtual machines using the onevm command or Sunstone. In Sunstone, you can easily instantiate currently defined

documentation:archives:rel3.4:vnet_template

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page describes how to define a new Virtual Network template. A Virtual Network template follows the same syntax as the VM template. If you want to learn more about the Virtual Network management, you can do so here. Common Attributes There are two types of Virtual Networks, ranged and fixed. Their only difference is how the leases are defined in the template.

documentation:archives:rel3.4:x509_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This guide will show you how to enable and use the x509 certificates authentication with OpenNebula. The x509 certificates can be used in two different ways in OpenNebula. The first option that is explained in this guide enables us to use certificates with the CLI. In this case the user will generate a login token with his private key, OpenNebula will validate the certificate and decrypt the token to authenticate the user.

documentation:archives:rel3.4:xeng

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

The XEN hypervisor offers a powerful, efficient and secure feature set for virtualization of x86, IA64, PowerPC and other CPU architectures. It delivers both paravirtualization and full virtualization. This guide describes the use of Xen with OpenNebula, please refer to the Xen specific documentation for further information on the setup of the Xen hypervisor itself.

documentation:archives:rel3.4:zona

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

This page contains the OpenNebula Zone API (ZONA) Specification for Ruby. It has been designed as a wrapper for the OpenNebula Zone REST server, with some basic helpers. This means that you should be familiar with the XML-RPC API and the JSON formats returned by the OpenNebula Zone server.

documentation:archives:rel3.4:zonesmngt

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:54+00:00

A Zone is essentially a group of interconnected physical hosts with hypervisors controlled by OpenNebula. A Zone can be added to the oZones server, providing valid oneadmin credentials, so it can contribute to the list of aggregated resources presented by the oZones component. A Zone can be further