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 information on this model see the Cloud Bursting overview

The remote cloud provider will be included in the OpenNebula host pool like any other physical host of your infrastructure:

<xterm> $ onehost create remote_provider im_provider vmm_provider tm_dummy dummy

$ onehost list

ID NAME            CLUSTER   RVM      ALLOCATED_CPU      ALLOCATED_MEM STAT
 2 kvm-            -           0       0 / 800 (0%)      0K / 16G (0%) on
 3 kvm-1           -           0       0 / 100 (0%)     0K / 1.8G (0%) on
 4 remote_provider -           0       0 / 500 (0%)     0K / 8.5G (0%) on

</xterm>

When you create a new host in OpenNebula you have to specify the following parameters:

• Name: remote_provider

Name of the host, in case of physical hosts it will the ip address or hostname of the host. In case of remote providers it will be just a name to identify the provider.

• Information Manager: im_provider

IM driver gather information about the physical host and hypervisor status, so the OpenNebula scheduler knows the available resources and can deploy the virtual machines accordingly.

• VirtualMachine Manager: vmm_provider

VMM drivers translate the high-level OpenNebula virtual machine life-cycle management actions, like deploy, shutdown, etc. into specific hypervisor operations. For instance, the KVM driver will issue a virsh create command in the physical host. The EC2 driver translate the actions into Amazon EC2 API calls.

• Transfer Manager: tm_dummy

TM drivers are used to transfer, clone and remove Virtual Machines Image files. They take care of the file transfer from the OpenNebula image repository to the physical hosts. There are specific drivers for different storage configurations: shared, non-shared, lvm storage, etc.

• VirtualNetwork Manager: dummy

VNM drivers are used to set the network configuration in the host (firewall, 802.1Q, ebtables, osvswitch)

When creating a new host to interact with a remote cloud provider we will use mock versions for the TM and VNM drivers. Therefore, we will only implement the functionality required for the IM and VMM driver.

Add a new IM section for the new driver in oned.conf:

#*******************************************************************************
# Information Driver Configuration
#*******************************************************************************
# You can add more information managers with different configurations but make
# sure it has different names.
#
#   name      : name for this information manager
#
#   executable: path of the information driver executable, can be an
#               absolute path or relative to $ONE_LOCATION/lib/mads (or
#               /usr/lib/one/mads/ if OpenNebula was installed in /)
#
#   arguments : for the driver executable, usually a probe configuration file,
#               can be an absolute path or relative to $ONE_LOCATION/etc (or
#               /etc/one/ if OpenNebula was installed in /)
#    -r number of retries when monitoring a host
#    -t number of threads, i.e. number of hosts monitored at the same time
#*******************************************************************************
#-------------------------------------------------------------------------------
#  EC2 Information Driver Manager Configuration
#-------------------------------------------------------------------------------
IM_MAD = [
      name       = "im_provider",
      executable = "one_im_sh",
      arguments  = "-t 1 -r 0 provider_name" ]
#-------------------------------------------------------------------------------

Create a new directory to store your probes, the name of this folder must match the name provided in the arguments section of the IM_MAD in oned.conf:

• /var/lib/one/remotes/im/<provider_name>.d

These probes must return:

• Information of the host capacity, to limit the number of VMs that can be deployed in this hosts.
• Information of the VMs running in this host-

You can see an example of these probes in the ec2 driver (code) included in OpenNebula

You must include the PUBLIC_CLOUD and HYPERVISOR attributes as one of the values returned by your probes, otherwise OpenNebula will consider this host as local. The HYPERVISOR attribute will be used by the scheduler and should match the TYPE value inside the PUBLIC_CLOUD section provided in the VM template.

PUBLIC_CLOUD="YES"
HYPERVISOR="provider_name"

#*******************************************************************************
# Virtualization Driver Configuration
#*******************************************************************************
# You can add more virtualization managers with different configurations but
# make sure it has different names.
#
#   name      : name of the virtual machine manager driver
#
#   executable: path of the virtualization driver executable, can be an
#               absolute path or relative to $ONE_LOCATION/lib/mads (or
#               /usr/lib/one/mads/ if OpenNebula was installed in /)
#
#   arguments : for the driver executable
#    -r number of retries when monitoring a host
#    -t number of threads, i.e. number of hosts monitored at the same time
#
#   default   : default values and configuration parameters for the driver, can
#               be an absolute path or relative to $ONE_LOCATION/etc (or
#               /etc/one/ if OpenNebula was installed in /)
#
#   type      : driver type, supported drivers: xen, kvm, xml
#-------------------------------------------------------------------------------
VM_MAD = [
    name       = "vmm_provider",
    executable = "one_vmm_sh",
    arguments  = "-t 15 -r 0 provider_name",
    type       = "xml" ]
#-------------------------------------------------------------------------------

Create a new folder inside the remotes dir (/var/lib/one/remotes/vmm). The new folder should be named “providet_name”, the name specified in the previous VM_MAD arguments section.

This folder must contain scripts for the supported actions. You can see the list of available actions in the Virtual Machine Driver guide. These scripts are language-agnostic so you can implement them using python, ruby, bash…

You can see examples on how to implement this in the ec2 driver:

• EC2 Shutdown action:

#!/usr/bin/env ruby
 
# -------------------------------------------------------------------------- #
# Copyright 2010-2013, C12G Labs S.L                                         #
#                                                                            #
# Licensed under the Apache License, Version 2.0 (the "License"); you may    #
# not use this file except in compliance with the License. You may obtain    #
# a copy of the License at                                                   #
#                                                                            #
# http://www.apache.org/licenses/LICENSE-2.0                                 #
#                                                                            #
# Unless required by applicable law or agreed to in writing, software        #
# distributed under the License is distributed on an "AS IS" BASIS,          #
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.   #
# See the License for the specific language governing permissions and        #
# limitations under the License.                                             #
# -------------------------------------------------------------------------- #
 
$: << File.dirname(__FILE__)
 
require 'ec2_driver'
 
deploy_id = ARGV[0]
host      = ARGV[1]
 
ec2_drv = EC2Driver.new(host)
 
ec2_drv.shutdown(deploy_id)

After restarting oned we can create the new host that will use this new driver <xterm> $ onehost create remote_provider im_provider vmm_provider tm_dummy dummy </xterm>

Create a new VM using a template with an specific section for this provider. You have to include the required information to start a new VM inside the PUBLIC_CLOUD section, and the TYPE attribute must match the HYPERVISOR value of the host. For example: <xterm> $ cat vm_template.one CPU=1 MEMORY=256 PUBLIC_CLOUD=[

  TYPE=provider_name
  PROVIDER_IMAGE_ID=id-141234,
  PROVIDER_INSTANCE_TYPE=small_256mb

]

$ onevm create vm_template ID: 23

$ onevm deploy 23 remote_provider </xterm> After this, the deploy script will receive the following arguments:

• The path to the deployment file that contains the following XML:

<CPU>1</CPU>
<MEMORY>256</MEMORY>
<PUBLIC_CLOUD>
    <TYPE>provider_name</TYPE>
    <PROVIDER_IMAGE_ID>id-141234</PROVIDER_IMAGE_ID>
    <PROVIDER_INSTANCE_TYPE>small_256mb</PROVIDER_INSTANCE_TYPE>
</PUBLIC_CLOUD>

• The hostname: remote_provider
• The VM ID: 23

The deploy script has to return the ID of the new resource and an exit_code 0: <xterm> $ cat /var/lib/one/remote/provider/deploy #!/bin/bash deployment_file=$1 # Parse required parameters from the template .. # Retrieve account credentials from a local file/env … # Create a new resource using the API provider … # Return the provider ID of the new resource and exit code 0 or an error message </xterm>