Infrastructure Drivers on

Overview

Mon, 17 Feb 2025 00:00:00 +0000

The interactions between OpenNebula and the Cloud infrastructure are performed by specific drivers. Each one addresses a particular area:

Storage. The OpenNebula core issue abstracts storage operations (e.g., clone or delete) that are implemented by specific programs that can be replaced or modified to interface special storage backends and file-systems.
Virtualization. The interaction with the hypervisors are also implemented with custom programs to boot, stop, or migrate a Virtual Machine. This allows you to specialize each VM operation so as to perform custom operations.
Monitoring. Monitoring information is also gathered by external probes. You can add additional probes to include custom monitoring metrics that can later be used to allocate Virtual Machines or for accounting purposes.
Authentication. OpenNebula can be also configured to use an external program to authorize and authenticate user requests. In this way, you can implement any access policy to Cloud resources.
Networking. The hypervisor is also prepared with the network configuration for each Virtual Machine.

Use the driver interfaces if you need OpenNebula to interface any specific storage, virtualization, monitoring, or authorization system already deployed in your data center, or to tune the behavior of the standard OpenNebula drivers.

Virtualization Driver

Mon, 17 Feb 2025 00:00:00 +0000

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 able to translate basic VMM actions to the hypervisor.

Storage Driver

Mon, 17 Feb 2025 00:00:00 +0000

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 with instantiated VMs.

Datastore Drivers Structure

Located under /var/lib/one/remotes/datastore/<ds_mad>

cp: copies/dumps the image to the datastore
- ARGUMENTS: image_id
- STDIN: datastore_image_dump
- RETURNS: image_source image_format
- datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
- image_source is the image source which will be later sent to the transfer manager.
mkfs: creates a new empty image in the datastore
- ARGUMENTS: image_id
- STDIN: datastore_image_dump
- RETURNS: image_source
- datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
- image_source is the image source which will be later sent to the transfer manager.
rm: removes an image from the datastore
- ARGUMENTS: image_id
- STDIN: datastore_image_dump
- RETURNS: -
- datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
stat: returns the size of an image in Mb
- ARGUMENTS: image_id
- STDIN: datastore_image_dump
- RETURNS: size
- datastore_image_dump is an XML dump of the driver action encoded in Base 64. See a decoded example.
- size the size of the image in Mb.

Monitoring Driver

Mon, 17 Feb 2025 00:00:00 +0000

The Monitoring Drivers (or IM drivers) collect Host and Virtual Machine monitoring data by executing a monitoring agent in the Hosts. The agent periodically executes probes to collect data and periodically send this to the Front-end.

This guide describes the internals of the monitoring system. It is also a starting point on how to create a new IM driver from scratch.

Message structure

The structure of monitoring message is:

Networking Driver

Mon, 17 Feb 2025 00:00:00 +0000

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 first requirement is to make a new directory with the name of the driver in /var/lib/one/remotes/vnm/<name> with these files:

pre: This driver should perform all the network related actions required before the Virtual Machine starts in a Host.
post: This driver should perform all the network related actions required after the Virtual Machine starts (actions which typically require the knowledge of the tap interface the Virtual Machine is connected to).
clean: If any clean-up should be performed after the Virtual Machine shuts down, it should be placed here.
vnet_create: Virtual Network is being added to OpenNebula, do driver initialization.
vnet_delete: Virtual Network is being removed from OpenNebula, do a clean-up.

Warning

The above three files must exist. If no action is required in them a simple exit 0 will be enough.

Warning

Remember that any change in the /var/lib/one/remotes directory won’t be effective in the Hosts until you execute, as oneadmin: onehost sync -f

Virtual Machine actions and their relation with Network actions:

Authentication Driver

Mon, 17 Feb 2025 00:00:00 +0000

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 for getting the user credentials from the OpenNebula database and they login and answer whether the authentication is correct or not.

Market Driver

Mon, 17 Feb 2025 00:00:00 +0000

The Market Driver is in charge of managing both Marketplaces and Marketplace Apps.

Marketplace Drivers Structure

The main drivers are located under /var/lib/one/remotes/market/<market_mad>. Marketplaces support the following operations:

Action	Description
`create`	Create a new Marketplace.
`monitor`	This automatic action discovers the available Marketplace Apps and monitors the available space of the Marketplace.
`delete`	Removes a Marketplace from OpenNebula. For a Public Marketplace, it will also remove the Marketplace Apps, but for any other type of Marketplace this will not remove the Marketplace Apps, and will only work if the Marketplace is empty.
other	Generic actions common to OpenNebula resources are also available: `update`, `chgrp`, `chown`, `chmod` and `rename`.

As for the Marketplace Apps, they support these actions:

IPAM Driver

Mon, 17 Feb 2025 00:00:00 +0000

An IPAM driver lets you delegate IP lease management to an external component. This way you can coordinate IP use with other virtual or bare-metal servers in your data center. To effectively use an external IPAM you need to develop four action scripts that hook on different points of the IP network/lease life-cycle.

Note that OpenNebula includes a built-in internal IPAM. You need to develop this component if you are using an IPAM server and want to coordinate OpenNebula with it.