This guide is aimed at OpenNebula 2.0 or 2.2 users and administrators who want to upgrade to the latest 3.0 version. The following sections summarize the new features and usage changes that should be taken into account, or prone to cause confusion.
OpenNebula Administrators
-
The columns format for one* list commands can be customized by editing the /etc/one/cli/*
files. You can change the size and name of the columns and define the columns to be shown in the default section. You can also copy this set of files to your home directory ($HOME/.one/cli
) if you want to customize them individually for each user.
The default filter flag for one* list commands is group. Administrators should take this into account and use one* list a instead to monitor all the existing resources.
Clusters don't exist anymore. Because clusters were basically a tagging system for Hosts, this functionality is extended by the possibility to store any arbitrary data in the Host templates, by using the
onehost update command. Existing cluster names are added to the previously assigned Hosts' templates by the
onedb command, so your existing placement REQUIREMENTS in VM templates will keep working as expected.
The Transfer Manager driver
tm_nfs has been renamed to
tm_shared. The
onedb upgrade process will rename the transfer driver of your existing hosts, but pay attention to this if you create new hosts.
-
In the small.erb file, the Network is defined by ID instead of name; i.e. NETWORK_ID = <id>
instead of NETWORK = <name>
.
The Network must belong to the same
Group as the users, and must be public.
The EC2_ACCESS_KEY
and EC2_SECRET_KEY
environment variables and CLI parameters now refer to the OpenNebula hashed password instead of the plain one. This way it follows the same model used in the rest of the EC2 tools (ec2-*, euca-*). The ONE_AUTH file still keeps the user:password format for the econe tools.
OpenNebula Users
There are two main differences in the way that users interact with OpenNebula:
1. New Template Resources
VM Templates now have to be registered and then instantiated. If you had a VM template file, say my_vm.one, this how you created a VM from it in 2.x:
<xterm>
$ onevm create my_vm.one
</xterm>
And this is how it is done in OpenNebula 3.0:
<xterm>
$ onetemplate create my_vm.one
ID: 0
$ onetemplate instantiate 0
VM ID: 1
$ onevm show 1
</xterm>
Think of the new Templates as the VM definitions available in OpenNebula, and the objects shown in onevm as the instances of those Templates.
2. Use IDs instead of Names
Resources have to be referenced by its ID in VM Templates. The following VM Template, valid for 2.x versions, will return an error:
<xterm>
$ cat old.vm
NAME = my_vm
DISK = [ IMAGE = img_one ]
$ onetemplate create old.vm
ID: 1
$ onetemplate instantiate 1
[TemplateInstantiate] Error allocating a new virtual machine. IMAGE is not supported for DISK.
Use IMAGE_ID instead.
</xterm>
Instead, you must use the IMAGE_ID and NETWORK_ID in your Templates:
<xterm>
$ cat new.vm
NAME = my_vm
DISK = [ IMAGE_ID = 0 ]
$ onetemplate create new.vm
ID: 2
$ onetemplate instantiate 2
VM ID: 2
</xterm>
Note that you can still continue using the resource names in the CLI, e.g. 'oneimage show img_one' or 'onevm shutdown my_vm'.
The following list describes other features and different commands usage that you should be aware of:
When a resource is created, the ID is returned even without the –verbose (-v)
option.
You can customize the columns format for 'one* list' commands, see the above section.
The range format for operations that allow multiple resource IDs is now in the form '1,3,8..11'.
Options have to be defined after the sub-command:
WRONG: $ onevm -x list
RIGHT: $ onevm list -x
The default filter flag for 'one* list' commands is group, which shows resources in your group. Use 'one* list m' to see only yours.
The public flag for resources has a new scope: public resources can be seen and used by other users in your group, but they are unreachable for other users in the system.
You can use 'oneuser show' to find out your user ID.
VMware users won't no longer have to use the 'onevmware' command to register images. Instead, the normal 'oneimage' command
can handle VMware disks in OpenNebula 3.0.
Developers and Integrators
-
Developers using the
Ruby or
Java OCA should check the updated documentation. Not only new classes have been added for the new functionality (Templates,
ACL, Groups, etc); but also some of the existing methods use different arguments.
If you use the XML-RPC
API directly, then check the differences between the
2.2 and
3.0 XML-RPC
API documentation. There are new methods, as well as some changes in the number of required arguments for some of the methods.
The authentication token is the same as in previous versions: “user:password”. The core expects the string “user:sha1(password)”. But if you activate the
external Authentication drivers, then the authentication token generated with the
oneuser login
command looks like “user:protocol:password”. In this case, the unmodified token must be sent in the xml-rpc call. This can be better understood in the
ruby OCA Client class.
Until OpenNebula 2.2, the file copy or creation for Image allocation had to be performed by the oneimage command or the client application. Since 3.0, the file management is done entirely by the OpenNebula core. Take a look at the
Image Manager Driver documentation for more info.
The XML objects returned by OpenNebula have changed to accommodate the new features. Download the XML Schemas (XSD) for
2.2 and 3.0 versions to compare them (3.0 XSD will be available soon).