OpenNebula - Flexible Enterprise Cloud Made Simple documentation:rel4.4

documentation:rel4.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 retrieved from OpenNebula. This accounting tool addresses the accounting of the virtual resources. It includes resource consumption of the virtual machines as reported from the hypervisor.

documentation:rel4.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:rel4.4:appflow_api

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

Overview The OpenNebula OneFlow API is a RESTful service to create, control and monitor multi-tier applications or services composed of interconnected Virtual Machines with deployment dependencies between them. Each group of Virtual Machines is deployed and managed as a single entity, and is completely integrated with the advanced OpenNebula user and group management. There are two kind of resources; services templates and services. All data is sent and received as JSON.

documentation:rel4.4:appflow_configure

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

The OneFlow commands do not interact directly with the OpenNebula daemon, there is a server that takes the requests and manages the service (multi-tiered application) life-cycle. This guide shows how to start OneFlow, and the different options that can be configured.

documentation:rel4.4:appflow_elasticity

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

A role's cardinality can be adjusted manually, based on metrics, or based on a schedule. Overview When a scaling action starts, the Role and Service enter the SCALING state. In this state, the Role will instantiate or shutdown a number of VMs to reach its new cardinality.

documentation:rel4.4:appflow_use_cli

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

OneFlow allows users and administrators to define, execute and manage multi-tiered applications, or services composed of interconnected Virtual Machines with deployment dependencies between them. Each group of Virtual Machines is deployed and managed as a single entity, and is completely integrated with the advanced

documentation:rel4.4:appmarket_configure

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

Requirements AppMarket requires: * MongoDB * ruby and rubygems installed. * bundler. To install it you can issue as root: # gem install bundler * Required gems. To install the gems needed by AppMarket do this as root: # cd /usr/lib/one/ruby/oneapps/market # bundle install

documentation:rel4.4:auth_overview

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.4:bcont

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

This guide shows how to automatically configure networking in the initialization process of the VM. Following are the instructions to contextualize your images to configure the network. For more in depth information and information on how to use this information for other duties head to the

documentation:rel4.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:rel4.4:catalog

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.4:ceph_ds

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

The Ceph datastore driver provides OpenNebula users with the possibility of using Ceph block devices as their Virtual Images. :!: This driver only works with libvirt/KVM drivers. Xen is not (yet) supported. :!: This driver requires that the OpenNebula nodes using the Ceph driver must be part of a running Ceph cluster. More information in

documentation:rel4.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:rel4.4:cli

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

OpenNebula provides a set commands to interact with the system: CLI * oneacct: gets accounting data from OpenNebula * oneacl: manages OpenNebula ACLs * onecluster: manages OpenNebula clusters * onedatastore: manages OpenNebula datastores * onedb: OpenNebula database migration tool

documentation:rel4.4:cloud-init

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

Since version 0.7.3 of cloud-init packages the OpenNebula context CD is supported. It is able to get and configure networking, hostname, ssh key for root and cloud-init user data. Here are the options in a table: Option Description standard network options

documentation:rel4.4:cloud_app_management_overview

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

OneFlow and OneGate provide functionality to integrate OpenNebula with the applications running inside your Virtual Machines. They are two different servers, read the Cloud Application Overview for information on how to configure and start them. OneFlow OneGate OneGate allows Virtual Machine guests to push monitoring information to OpenNebula. Users and administrators can use it to gather metrics, detect problems in their applications, and trigger OneFlow auto-scaling rules

documentation:rel4.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:rel4.4:cloud_view

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

This is a simplified view mainly intended for cloud consumers that just require a portal where they can provision new virtual machines easily. They just have to select one of the available templates and the operating system that will run in this virtual machine. For more information about the suntone views, please check the following

documentation:rel4.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:rel4.4:compatibility

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

This guide is aimed at OpenNebula 4.2 users and administrators who want to upgrade to the latest 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:rel4.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:rel4.4:cong

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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. You can use already made packages that install context scripts and prepare udev configuration in your appliances. This is described in

documentation:rel4.4:contextualization_packages

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

Contextualization packages are available to several distributions so you can prepare them to work with OpenNebula without much effort. These are the changes they do to you VM: * Disables udev net and cd persistent rules * Deletes udev net and cd persistent rules

documentation:rel4.4:context_overview

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

OpenNebula provides different methods to pass information to a newly created Virtual Machine. This information can be the network configuration of the VM, user credentials, init scripts and free form data. * Basic Contextualization: If you only want to configure networking and root ssh keys read this guide.

documentation:rel4.4:devel-auth

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

This guide will show you how to develop a new driver for OpenNebula to interact with an external authentication service. OpenNebula comes with an internal user/password way of authentication, this is called “core”. To be able to use other auth methods there is a system that performs authentication with external systems. Authentication drivers are responsible of getting the user credentials from OpenNebula database and login and answer whether the authentication is correct or not.

documentation:rel4.4:devel-cloudbursting

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

This guide will show you how to develop a new driver for OpenNebula to interact with an external cloud provider. Overview Cloud bursting is a model in which the local resources of a Private Cloud are combined 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 cloud bursting enables highly scalable hosting environments. For more informatio…

documentation:rel4.4:devel-im

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

The Monitoring Drivers (or IM drivers) collect host and virtual machine monitoring data by executing a set of probes in the hosts. This data is either actively queried by OpenNebula or sent periodically by an agent running in the hosts to the frontend.

documentation:rel4.4:devel-nm

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

This component is in charge of configuring the network in the hypervisors. The purpose of this guide is to describe how to create a new network manager driver. Driver Configuration and Description To enable a new network manager driver, the only requirement is to make a new directory with the name of the driver in

documentation:rel4.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:rel4.4:ds_conf

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

Datastores can be parametrized with several parameters. In the following list there are the meaning of the different parameters for all the datastores. * RESTRICTED_DIRS: Paths not allowed for image importing * SAFE_DIRS: Paths allowed for image importing

documentation:rel4.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:rel4.4:ec2g

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

Considerations & Limitations 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).

documentation:rel4.4:ec2qcg

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.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:rel4.4:ec2qec

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.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.

documentation:rel4.4:esx5persistency

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

Most of ESX 5 files reside in a in-memory filesystem. This means faster access and also non persistency across reboots, which can be inconvenient at the time of managing a ESX farm for a OpenNebula cloud. Here is a recipe to make the configuration needed for OpenNebula persistent across reboots. The changes need to be done as root.

documentation:rel4.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. They use libvirt and direct API calls using RbVmomi to invoke the Virtual Infrastructure SOAP API exposed by the VMware hypervisors, and feature a simple configuration process that will leverage the stability, performance and feature set of any existing VMware based OpenNebula cloud.

documentation:rel4.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 system, see the Users & Groups Subsystem guide for more information. You can enable an external Authentication driver. Authentication In the figure to the right of this text you can see three authentication configurations you can customize in OpenNebula.

documentation:rel4.4:features

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

This section describes the detailed features and functionality of the latest version of OpenNebula (v4.4) for the management of private clouds and datacenter virtualization(*). It includes links to the different parts of the documentation and the web site that provide extended information about each feature. We also provide a summarized table of

documentation:rel4.4:file_ds

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

The Files Datastore lets you store plain files to be used as VM kernels, ramdisks or context files. The Files Datastore does not expose any special storage mechanism but a simple and secure way to use files within VM templates. There is a Files Datastore (datastore ID: 2) ready to be used in OpenNebula.

documentation:rel4.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:rel4.4:fs_ds

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

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:rel4.4:fs_lvm_ds

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

Overview The FS LVM datastore driver provides OpenNebula with the possibility of using LVM volumes instead of plain files to hold the Virtual Images. It is assumed that the OpenNebula hosts using this datastore will be configured with CLVM, therefore modifying the OpenNebula Volume Group in one host will reflect in the others.

documentation:rel4.4:ftguide

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

OpenNebula delivers the availability required by most applications running in virtual machines. This guide's objective is to provide information in order to prepare for failures in the virtual machines or physical nodes, and recover from them. These failures are categorized depending on whether they come from the physical infrastructure (Host failures) or from the virtualized infrastructure (VM crashes). In both scenarios, OpenNebula provides a cost-effective failover solution to minimize downti…

documentation:rel4.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:rel4.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:rel4.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:rel4.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:rel4.4:hostsubsystem

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

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 these requirements are fulfilled:

documentation:rel4.4:host_guide

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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. kvm. These should match the Virtualization Drivers installed and more info about them can be found at the

documentation:rel4.4:ignc

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

This page shows you how to install OpenNebula from the binary packages. Step 1. Front-end Installation Using the packages provided in our site is the recommended method, to ensure the installation of the latest version and to avoid possible packages divergences of different distributions. There are two alternatives here, to install OpenNebula you can add

documentation:rel4.4:ignc2

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. 1. Package Installation 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. 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 …

documentation:rel4.4:ignc3

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

documentation:rel4.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:rel4.4:imesxpullg

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

Requirements * VI API access to the ESX hosts. * ESX hosts configured to work with OpenNebula OpenNebula Configuration In order to configure VMware you need to: * Enable the VMware monitoring driver in /etc/one/oned.conf by uncommenting the following lines:

documentation:rel4.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:rel4.4:img_mad

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.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:rel4.4:imsshpullg

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

KVM and Xen can be monitored with this ssh based monitoring system. The OpenNebula frontend starts a driver which triggers ssh connections to the hosts which return the monitoring information of the host and of all the virtual machines running within.

documentation:rel4.4:imudppushg

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

KVM and Xen can be monitored with this UDP based monitoring system. Monitorization data is sent from each host to the frontend periodically via UDP by an agent. This agent is started by the initial bootstrap system of the monitoring system which is performed via

documentation:rel4.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 a simple but feature-rich and flexible solution to build and manage enterprise clouds and virtualized data centers. This introductory guide gives an overview of OpenNebula and summarizes its main benefits for the different stakeholders involved in a cloud computing infrastructure.

documentation:rel4.4:introapis

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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 Guide we review the main interfaces of OpenNebula, their use and give pointers to additional documentation for each one.

documentation:rel4.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:rel4.4:introh

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

Cloud bursting is a model in which the local resources of a Private Cloud are combined 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 cloud bursting enables highly scalable hosting environments.

documentation:rel4.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:rel4.4:java

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.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 4.4 version, and will be solved in future releases. VMware * No multi boot support OneFlow * #2535: VM creation fails if role name has a space. Patch in ticket. Drivers - Auth *

documentation:rel4.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:rel4.4:ldap

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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 requires the

documentation:rel4.4:log_debug

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

OpenNebula provides logs for many resources. It supports two logging systems: file based logging systems and syslog logging. In the case of file based logging, OpenNebula keeps separate log files for each active component, all of them stored in /var/log/one

documentation:rel4.4:lvm

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

The LVM TM driver is an alternative to tm_shared and tm_ssh driver. It features instantaneous image deployment through LVM snapshots. Requirements LVM must be available in the Hosts. The oneadmin user should be able to execute several LVM related commands with sudo passwordlessly.

documentation:rel4.4:lvm_drivers

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

The LVM datastore driver provides OpenNebula with the possibility of using LVM volumes instead of plain files to hold the Virtual Images. This reduces the overhead of having a file-system in place and thus increases performance. Overview OpenNebula ships with two sets of LVM drivers:

documentation:rel4.4:lvm_ds

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

Overview The Block LVM datastore driver provides OpenNebula with the possibility of using LVM volumes instead of plain files to hold the Virtual Images. It is assumed that the OpenNebula hosts using this datastore will be configured with CLVM, therefore modifying the OpenNebula Volume Group in one host will reflect in the others. There is a special list of hosts (BRIDGE_LIST) which belong to the LVM cluster, that will be the ones OpenNebula uses to speak to when doing LVM operations.

documentation:rel4.4:lvm_overview

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

Overview OpenNebula provides LVM support in two flavours: * LVM: the classical OpenNebula approach. * Shared LVM: the new approach designed to work with multiple system datastores. Overview of LVM and Shared LVM LVM Shared LVM

documentation:rel4.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:rel4.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:rel4.4:marketplace

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

The OpenNebula Marketplace is a catalog of third party virtual appliances ready to run in OpenNebula environments. The OpenNebula Marketplace only contains appliances metadata. The images and files required by an appliance will not be stored in the Marketplace, but links to them.

documentation:rel4.4:mon

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

This guide provides an overview of the OpenNebula monitoring subsystem. The monitoring subsystem gathers information relative to the hosts and the virtual machines, such as the host status, basic performance indicators, as well as VM status and capacity consumption. This information is collected by executing a set of static probes provided by OpenNebula. The output of these probes is sent to OpenNebula in two different ways: using a push or a pull paradigm. Below you can find a brief description…

documentation:rel4.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:rel4.4:nm

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

Before diving into Network configuration in OpenNebula make sure that you've followed the steps described in the Networking section of 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:rel4.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:rel4.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:rel4.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:rel4.4:oneapps_installation

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

The installation of the software is really easy. You only need to download the package for your distribution and install it using the package manager. Configuration and external dependencies are described in each app's documentation. Planning the Installation

documentation:rel4.4:oneapps_overview

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

documentation:rel4.4:onedb

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

This guide describes the onedb CLI tool. It can be used to get information from an OpenNebula database, upgrade it, or fix inconsistency problems. Connection Parameters The command onedb can connect to any SQLite or MySQL database. Visit the onedb man page for a complete reference. These are two examples for the default databases:

documentation:rel4.4:oned_conf

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

The OpenNebula daemon oned manages the cluster nodes, virtual networks, virtual machines, users, groups and storage datastores. 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:rel4.4:onegate_configure

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

The OneGate service allows Virtual Machines guests to push monitoring information to OpenNebula. Althouth it is installed by default, its use is completely optional. Requirements Check the Installation guide for details of what package you have to install depending on your distribution

documentation:rel4.4:onegate_overview

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

documentation:rel4.4:onegate_usage

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

OneGate allows Virtual Machine guests to push monitoring information to OpenNebula. Users and administrators can use it to gather metrics, detect problems in their applications, and trigger OneFlow elasticity rules. OneGate Workflow Explained OneGate is a server that listens to http connections from the Virtual Machines. OpenNebula assigns an individual token to each VM instance, and Applications running inside the VM use this token to send monitoring metrics to OneGate.

documentation:rel4.4:oneha

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

This guide walks you through the process of setting a high available cluster for OpenNebula. The ultimate goal is to reduce downtime of core OpenNebula services: core (oned), scheduler (mm_sched) and Sunstone interface (sunstone-server). We will be using the classical active-passive cluster architecture which is the recommended solution for OpenNebula. In this solution two (or more) nodes will be part of a cluster where the OpenNebula daemon, scheduler and Sunstone (web UI) are cluster resource…

documentation:rel4.4:one_scalability

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

Monitoring OpenNebula supports two native monitoring systems: ssh-pull and udp-push. The former one, ssh-pull is the default monitoring system for OpenNebula <=4.2, however from OpenNebula 4.4 onwards, the default monitoring system is the udp-push

documentation:rel4.4:openvswitch

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

This guide describes how to use the Open vSwitch network drives. They provide two indepent functionalities that can be used together: network isolation using VLANs, and network filtering using OpenFlow. 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.

documentation:rel4.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:rel4.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:rel4.4:plan

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

In order to get the most out of a OpenNebula Cloud, we recommend that you create a plan with the features, performance, scalability, and high availability characteristics you want in your deployment. This guide provides information to plan an OpenNebula installation, so you can easily architect your deployment and understand the technologies involved in the management of virtualized resources and their relationship.

documentation:rel4.4:qs_centos_kvm

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

The purpose of this guide is to provide users with step by step guide to install OpenNebula using CentOS 6 as the operating system and KVM as the hypervisor. After following this guide, users will have a working OpenNebula with graphical interface (Sunstone), at least one hypervisor (host) and a running virtual machines. This is useful at the time of setting up pilot clouds, to quickly test new features and as base deployment to build a large infrastructure.

documentation:rel4.4:qs_centos_vmware

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

This guide aids in the process of quickly get a VMware-based OpenNebula cloud up and running on CentOS. This is useful at the time of setting up pilot clouds, to quickly test new features and as base deployment to build a large infrastructure. Package Layout

documentation:rel4.4:qs_centos_xen

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

The purpose of this guide is to provide users with step by step guide to install OpenNebula using CentOS 6 as the operating system and Xen as the hypervisor. After following this guide, users will have a working OpenNebula with graphical interface (Sunstone), at least one hypervisor (host) and a running virtual machines. This is useful at the time of setting up pilot clouds, to quickly test new features and as base deployment to build a large infrastructure.

documentation:rel4.4:qs_ubuntu_kvm

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

The purpose of this guide is to provide users with step by step guide to install OpenNebula using Ubuntu 12.04 as the operating system and KVM as the hypervisor. After following this guide, users will have a working OpenNebula with graphical interface (Sunstone), at least one hypervisor (host) and a running virtual machines. This is useful at the time of setting up pilot clouds, to quickly test new features and as base deployment to build a large infrastructure.

documentation:rel4.4:quota_auth

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

This guide will show you how to set the usage quotas for users and groups. Overview The quota system tracks user and group usage of system resources, and allows the system administrator to set limits on the usage of these resources. Quota limits can be set for:

documentation:rel4.4:router

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

This guide describes how to use the Virtual Router in OpenNebula. Overview When instantiated in a network, this appliance provides the following services for other Virtual Machines running in the same network: * Router (masquerade) * Port forwarding *

documentation:rel4.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:rel4.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:rel4.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:rel4.4:sd_dump

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

0 0 0 oneadmin oneadmin ttylinux 1 1 0 0 0 0 0 0 0<…

documentation:rel4.4:selfservice

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.4:selfservicebranding

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.4:sm

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

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:rel4.4:ssh_auth

Anonymous (anonymous@undisclosed.example.com) — 2014-01-07T11:47:55+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:rel4.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:rel4.4:sunstone_server_plugin_guide

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

OpenNebula Sunstone server plugins consist a set files defining custom routes. Custom routes will have priority over default routes and allow administrators to integrate their own custom controllers in the Sunstone Server. Configuring Sunstone Server Plugins It is very easy to enable custom plugins:

documentation:rel4.4:suns_advance

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

Low to medium enterprise clouds will typically deploy Sunstone in a single machine a long with the OpenNebula daemons. However this simple deployment can be improved by: * Isolating the access from Web clients to the Sunstone server. This can be achieved by deploying the Sunstone server in a separated machine.

documentation:rel4.4:suns_auth

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

By default Sunstone works with the core authentication method (user and password) although you can configure any authentication mechanism supported by OpenNebula. In this guide you will learn how to enable other authentication methods and how to secure the Sunstone connections through SSL.

documentation:rel4.4:suns_usage

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

Login If you want to interact with Sunstone you have to open a new browser and go to the url where your Sunstone server is deployed. You will find the login screen where the username and password correspond to the OpenNebula credentials. After logging into Sunstone, the view defined in

documentation:rel4.4:suns_views

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

Using the new OpenNebula Sunstone Views you will be able to provide a simplified UI aimed at end-users of an OpenNebula cloud. The OpenNebula Sunstone Views are fully customizable, so you can easily enable or disable specific information tabs or action buttons. You can define multiple cloud views for different user groups. Each view defines a set of UI components so each user just access and view the relevant parts of the cloud for her role.

documentation:rel4.4:system_ds

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

The system datastore is a special Datastore class that holds images for running VMs. As opposed to the regular images datastores you cannot register new images into a system datastore. Types of System Datastore For each running VM in the datastore there is a directory containing the disk images and additional configuration files. For example, the structure of the system datastore 0 with 3 VMs (VM 0 and 2 running, and VM 7 stopped) could be: datastores

documentation:rel4.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:rel4.4:test

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

Value Code Meaning 0x0000 SUCCESS Success response. 0x0100 AUTHENTICATION User could not be authenticated. 0x0200 AUTHORIZATION User is not authorized to perform the requested action. 0x0400 NO_EXISTS The requested resource does not exist.

documentation:rel4.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 Release Notes to know what is new in OpenNebula 4.4.

documentation:rel4.4:uspng

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

This page will show you the specific considerations at the time of using an OpenNebula cloud, according to the different supported platforms. This is the list of the individual platform components that have been through the complete OpenNebula Quality Assurance and Certification Process. Certified Platform Component

documentation:rel4.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:rel4.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:rel4.4:vm4market

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

In this section some general guidelines on creating OpenNebula compatible images for the marketplace are described. Following this you will find a tutorial showing how to create an Ubuntu 12.04 image ready to distribute it in the marketplace. Image Creation Guidelines

documentation:rel4.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:rel4.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:rel4.4:vmwarenet

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

This guide describes how to use the VMware network driver in OpenNebula. 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:rel4.4:vmware_centos

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

This guide helps you to quickly get an OpenNebula cloud up and running. This is useful at the time of setting up pilot clouds, to quickly test new features and as a base deployment to build a large infrastructure. 1. Infrastructure Set-up The infrastructure needs to be set up in a similar fashion as the one depicted in the figure.

documentation:rel4.4:vmware_ds

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

In order to use VMware hypervisors in your OpenNebula cloud you will need to use VMFS Datastores. To configure them, it is important to keep in mind that there are (at least) two datastores to define, the system datastore (where the running VMs and their images reside, only need transfer manager drivers) and the

documentation:rel4.4:vm_guide

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

In OpenNebula the Virtual Machines are defined with Template 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:rel4.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. Virtual Machine Life-cycle The life-cycle of a Virtual Machine within OpenNebula includes the following stages:

documentation:rel4.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:rel4.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:rel4.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:rel4.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:rel4.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