OpenNebula features three different datastore types:
• The Images Datastore, stores the images repository.
• The System Datastore holds disk for running virtual machines, copied or cloned from the Images Datastore.
• The Files & Kernels Datastore to store plain files.
1.5.1 Datastore Management
Datastores are managed with the‘’onedatastore” command. In order to be operational an OpenNebula cloud needs at least one Image Datastore and one System Datastore.
Datastore Definition
A datastore definition includes specific attributes to configure its interaction with the storage system; and common attributes that define its generic behavior.
The specific attributes for System and Images Datastores depends on the storage:
• Define Filesystem Datastores.
• Define LVM Datastores.
• Define Ceph Datastores.
• Define Raw Device Mapping Datastores.
• Define iSCSI - Libvirt Datastores.
Also, there are a set of common attributes that can be used in any datastore and compliments the specific attributes for each datastore type described above for each datastore type.
Attribute Description
RESTRICTED_DIRS Paths that can not be used to register images. A space separated list of paths.
SAFE_DIRS If you need to un-block a directory under one of the RESTRICTED_DIRS. A space separated list of paths.
NO_DECOMPRESS Do not try to untar or decompress the file to be registered. Useful for specialized Transfer Managers
LIMIT_TRANSFER_BW Specify the maximum transfer rate in bytes/second when downloading images from a http/https URL. Suffixes K, M or G can be used.
DATASTORE_CAPACITY_CHECKIf yes, the available capacity of the datastore is checked before creating a new image LIMIT_MB The maximum capacity allowed for the datastore in MB.
BRIDGE_LIST Space separated list of hosts that have access to the storage to add new images to the datastore.
STAGING_DIR Path in the storage bridge host to copy an Image before moving it to its final destination. Defaults to /var/tmp.
The Files & Kernels Datastore is an special datastore type to store plain files to be used as kernels, ram-disks or context files. See here to learn how to define them.
1.5. Datastores 17
1.5.2 Multiple System Datastore Setup
In order to distribute efficiently the I/O of the Virtual Machines across different disks, LUNs or several storage back-ends, OpenNebula is able to define multiple System Datastores per cluster. Scheduling algorithms take into account disk requirements of a particular VM, so OpenNebula is able to pick the best execution host based on capacity and storage metrics.
Configuring Multiple Datastores
When more than one System Datastore is added to a cluster, all of them can be taken into account by the scheduler to place Virtual Machines into. System wide scheduling policies are defined in /etc/one/sched.conf. The storage scheduling policies are:
• Packing. Tries to optimize storage usage by selecting the Datastore with less free space.
• Striping. Tries to optimize I/O by distributing the Virtual Machines across Datastores.
• Custom. Based on any of the attributes present in the Datastore template.
To activate for instance the Stripping storage policy, /etc/one/sched.conf must contain:
DEFAULT_DS_SCHED = [ policy = 1
]
These policies may be overriden in the Virtual Machine Template, and so apply specific storage policies to specific Virtual Machines:
Attribute Description Example
SCHED_DS_REQUIREMENTSBoolean expression to select System Datastores (evaluates to true) to run a VM.
SCHED_DS_REQUIREMENTS="ID=100"
SCHED_DS_REQUIREMENTS="NAME=GoldenDS"
SCHED_DS_REQUIREMENTS=FREE_MB > 250000 SCHED_DS_RANKArithmetic expression to sort
the suitable datastores for this VM.
SCHED_DS_RANK= FREE_MB SCHED_DS_RANK=-FREE_MB
After a VM is deployed in a System Datastore, the admin can migrate it to another System Datastore. To do that, the VM must be firstpowered-off. The command onevm migrate accepts both a new Host and Datastore id, that must have the same TM_MAD drivers as the source Datastore.
Warning: Any Host belonging to a given cluster must be able to access any System or Image Datastore defined in that cluster.
Warning: Admins rights grant permissions to deploy a virtual machine to a certain datastore, using ‘onevm deploy’ command.
1.5.3 Disable a System Datastore
System Datastores can be disabled to prevent the scheduler from deploying new Virtual Machines in them. Datastores in the disabled state and monitored as usual, and the existing Virtual Machines will continue to run in them.
1.5. Datastores 18
$ onedatastore disable system -v DATASTORE 0: disabled
$ onedatastore show system DATASTORE 0 INFORMATION
ID : 0
NAME : system
...
STATE : DISABLED
...
1.5. Datastores 19
USERS AND GROUPS
2.1 Overview
OpenNebula includes a complete user & group management system. Users in an OpenNebula installation are classified in four types:
• Administrators, an admin user belongs to an admin group (oneadmin or otherwise) and can perform manage operations
• Regular users, that may access most OpenNebula functionality.
• Public users, only basic functionality (and public interfaces) are open to public users.
• Service users, a service user account is used by the OpenNebula services (i.e. cloud APIs like EC2 or GUI’s like Sunstone) to proxy auth requests.
The resources a user may access in OpenNebula are controlled by a permissions system that resembles the typical UNIX one. By default, only the owner of a resource (e.g. a VM or an image) can use and manage it. Users can easily share the resources by granting use or manage permissions to other users in her group or to any other user in the system.
Upon group creation, an associated admin user can be created. By default this user will be able to create users in the new group, and manage non owned resources for the regular group, through the CLI and/or a special Sunstone view.
This group can also be assigned to VDC, what is basically a pool of OpenNebula physical resources (hosts, datastores and virtual networks).
Along with the users & groups the Auth Subsystem is responsible for the authentication and authorization of user’s requests.
Any interface to OpenNebula (CLI, Sunstone, Ruby or Java OCA) communicates with the core using XML-RPC calls, that contain the user’s session string, which is authenticated by the OpenNebula core comparing the username and password with the registered users.
Each operation generates an authorization request that is checked against the registered ACL rules. The core then can grant permission, or reject the request.
OpenNebula comes with a default set of ACL rules that enables a standard usage. You don’t need to manage the ACL rules unless you need the level of permission customization if offers.
By default, the authentication and authorization is handled by the OpenNebula Core as described above. Optionally, you can delegate it to an external module, see the Authentication Guide for more information.
2.1.1 How Should I Read This Chapter
From these guides you should read at least the ones for Users, Groups and Permissions as are the basis for any cloud:
20
• Managing Users
These guides are compatible with both KVM and vCenter hypervisors.